conceiling function calls..

Discussion in 'Python' started by Carlo v. Dango, Nov 12, 2003.

  1. It is possible to conceil access to methods using the "property()"
    function so method access looks like field access.. is the same possible
    for functions (not taking any args... )

    I would like something like


    def f():
    return tnaheusnthanstuhn


    class A(object):
    def foo(self):
    f.bar()


    as it is now I have to write

    class A(object):
    def foo(self):
    f().bar()



    -carlo

    --
    Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
     
    Carlo v. Dango, Nov 12, 2003
    #1
    1. Advertising

  2. Carlo v. Dango wrote:

    > It is possible to conceil access to methods using the "property()"
    > function so method access looks like field access.. is the same possible
    > for functions (not taking any args... )


    It's possible as long as the functions are accessed as attributes of
    some object -- it may be horrible, but you CAN, if you wish, write a
    __getattribute__ for the "some object" to force any access to the
    attribute to become a CALL to that attribute.

    Thankfully, it at least can't be done for access to barenames.

    You could, of course, wrap the function into an object (of the
    same name if you wish) that calls it whenever "an attribute of that
    name" is accessed (SHUDDER).


    Alex
     
    Alex Martelli, Nov 13, 2003
    #2
    1. Advertising

  3. Thanks for your reply... Unfortunately, I cannot truly see your
    suggestions before my eyes..

    >> It is possible to conceil access to methods using the "property()"
    >> function so method access looks like field access.. is the same possible
    >> for functions (not taking any args... )

    >
    > It's possible as long as the functions are accessed as attributes of
    > some object -- it may be horrible, but you CAN, if you wish, write a
    > __getattribute__ for the "some object" to force any access to the
    > attribute to become a CALL to that attribute.


    but then I'm forced to use the self pointer.. I want to conceil it.



    > You could, of course, wrap the function into an object (of the
    > same name if you wish) that calls it whenever "an attribute of that
    > name" is accessed (SHUDDER).


    hmm Im not sure what you are suggesting here. Are you still making use of
    the self reference? or how would you construct this...

    please note that it's my purpose to hide the user from whats really going
    on..

    -carlo..



    --
    Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
     
    Carlo v. Dango, Nov 14, 2003
    #3
  4. On Wed, 12 Nov 2003 23:30:24 +0100, "Carlo v. Dango" <>
    wrote:

    >It is possible to conceil access to methods using the "property()"
    >function so method access looks like field access.. is the same possible
    >for functions (not taking any args... )
    >
    >I would like something like
    >
    >
    >def f():
    > return tnaheusnthanstuhn
    >
    >
    >class A(object):
    > def foo(self):
    > f.bar()
    >
    >
    >as it is now I have to write
    >
    >class A(object):
    > def foo(self):
    > f().bar()
    >


    Can you explain why you would want to do that? What possible gain can
    you have by counfounding name lookup with calling?

    Btw, as far as I know it can't be done. Even if functions were
    subclassable (and they're not) I just don't know how to instruct
    Python such that every time you look up a bare name referencing a
    function you end up calling it. But then again this request sounds so
    bizarre...

    With my best regards,
    G. Rodrigues
     
    Gonçalo Rodrigues, Nov 14, 2003
    #4
  5. Carlo v. Dango wrote:

    > Thanks for your reply... Unfortunately, I cannot truly see your
    > suggestions before my eyes..


    Yeah, sigh, I was keeping them shrouded in a pitiful veil of shame.
    What you ask is so horrible, unPythonic, and deleterious, that it IS,
    in a way, a shame that Python lets you do it at all. However, it does.

    Here, as in most other places, it DOES "give you enough rope to shoot
    yourself in the foot" if you get "clever" enough (note that "clever"
    is NOT seen as a _positive_ quality in Python...). It comes down to
    that "trust the programmer" dictum. Sometimes I wonder how factually
    founded it is. Oh well, maybe it's an ethical rather than pragmatical
    idea: trusting the programmers ensures your place in heaven, or
    something. I sure hope so... thus, here it comes.


    >>> It is possible to conceil access to methods using the "property()"
    >>> function so method access looks like field access.. is the same possible
    >>> for functions (not taking any args... )

    >>
    >> It's possible as long as the functions are accessed as attributes of
    >> some object -- it may be horrible, but you CAN, if you wish, write a
    >> __getattribute__ for the "some object" to force any access to the
    >> attribute to become a CALL to that attribute.

    >
    > but then I'm forced to use the self pointer.. I want to conceil it.


    That's a good part of what makes your request so horrible: you want
    to conceal what Python makes a point of revealing.


    >> You could, of course, wrap the function into an object (of the
    >> same name if you wish) that calls it whenever "an attribute of that
    >> name" is accessed (SHUDDER).

    >
    > hmm Im not sure what you are suggesting here. Are you still making use of
    > the self reference? or how would you construct this...
    >
    > please note that it's my purpose to hide the user from whats really going
    > on..


    Yes, sigh -- the most horrible, evil purpose one might imagine, just
    about. I truly hope you reconsider your intended course of action. Still:

    To recap: you have a global function f which when called w/o arguments
    returns an object on which attributes may be accessed, a la
    print f().someattr

    You want to HIDE (shudder) the fact that a function is being called,
    ensuring, instead, that just coding:
    print f.someattr
    will call f secretly, behind the scenes.

    If one was truly intent on perpetrating this horror, then:

    class DontLetKidsSeeThisPlease(object):
    def __init__(self, f): self.__f = f
    def __getattr__(self, name): return getattr(self.__f(), name)
    f = DontLetKidsSeeThisPlease(f)

    there -- that's all there is to it. If you ALSO want to still be
    able to call f() explicitly, add one more line to the class:
    def __call__(self): return self.__f()
    and now an explicit f() will also behave as a normal call to f.
    [One can of course also add attribute setting, and all other operations,
    but I do hope I don't have to show them all explicitly too...!!!]


    Alex
     
    Alex Martelli, Nov 14, 2003
    #5
  6. Gonçalo Rodrigues:
    > Can you explain why you would want to do that? What possible gain

    can
    > you have by counfounding name lookup with calling?
    >


    Well, I can't explain for the OP, but I found it (some years ago...
    I'm not sure I'd do the same thing now) convenient in a prototype
    minimalist database application. Data fields could always be inferred
    if not actually present in the instance. Thus when programming you
    could write:
    duedate = order.shipdate + order.terms.duedays
    without shipdate or terms being attributes of order.

    Similarly,
    lineextenion = lineitem.qty * lineitem.price
    without price or print the destination address without having
    designated a shipto.

    This allowed order entry to get along with only the minimum "how many
    of what go where" being entered. Everything else could be swizzled up
    when needed if not present. I specifically wanted the data structure
    to be an implementation detail.

    --

    Emile van Sebille
     
    Emile van Sebille, Nov 14, 2003
    #6
  7. Emile van Sebille wrote:

    > Gonçalo Rodrigues:
    >> Can you explain why you would want to do that? What possible gain

    > can
    >> you have by counfounding name lookup with calling?
    >>

    >
    > Well, I can't explain for the OP, but I found it (some years ago...
    > I'm not sure I'd do the same thing now) convenient in a prototype
    > minimalist database application. Data fields could always be inferred
    > if not actually present in the instance. Thus when programming you
    > could write:
    > duedate = order.shipdate + order.terms.duedays
    > without shipdate or terms being attributes of order.
    >
    > Similarly,
    > lineextenion = lineitem.qty * lineitem.price
    > without price or print the destination address without having
    > designated a shipto.
    >
    > This allowed order entry to get along with only the minimum "how many
    > of what go where" being entered. Everything else could be swizzled up
    > when needed if not present. I specifically wanted the data structure
    > to be an implementation detail.


    I see your use case as perfectly fine and totally unconnected to
    the OP's requirement. The concept of a property or dynamically
    fetched attribute of an object, such as your 'order' or 'lineitem',
    is perfectly fine (it is, however, valse that shipdate or terms
    would not be attributes of order -- hasattr would show this as
    being false -- if they can be accessed with this syntax, they ARE
    attributes, by Python's definition, even if they're computed via
    the property or __getattr__ routes).

    Having x.y "mean" x().y for some _function_ x is quite a different
    thing. _Functions_ don't have __getattr__ nor properties, they do
    have a simple dictionary where you can set arbitrary attributes
    and later fetch them back again, that's all. Properties and other
    dynamically computed/fetched attributes are typical of instamces of
    some user-coded classes that need such dynamism, not of functions.


    Alex
     
    Alex Martelli, Nov 14, 2003
    #7
  8. Carlo v. Dango

    Hung Jung Lu Guest

    Alex Martelli <> wrote in message news:<gq4tb.20498$>...
    >
    > You want to HIDE (shudder) the fact that a function is being called,
    > ensuring, instead, that just coding:
    > print f.someattr
    > will call f secretly, behind the scenes.
    >
    > If one was truly intent on perpetrating this horror, then:
    >
    > class DontLetKidsSeeThisPlease(object):
    > def __init__(self, f): self.__f = f
    > def __getattr__(self, name): return getattr(self.__f(), name)
    > f = DontLetKidsSeeThisPlease(f)


    I think the original poster was not very clear in his writing. But he
    did give an analogy. Let me try to guess what he wants.

    For a property implemented with getter and setter accessor methods,
    you can do a lot of things when the user accesses the property. A few
    examples are: (a) dynamically retrieve/store the value from/to a
    database, (b) do some logging or access security control, (c) return
    different values depending on environmental circumstances, etc.

    The original poster seems to want the same level of control for access
    to a global object inside a module. That's all. That is, he probably
    would like to: (a) dynamically assemble the object on the flight,
    perhaps from a database, perhaps some meta-programming, notice that a
    simple Python namespace entry CANNOT do this trick, because it always
    points to the same object. Sure, one way out in Python is to make a
    wrapper, but that's exactly what the original poster's "f" is about,
    (b) do some logging or security control everytime the object is
    accessed, (c) return different objects depending on environmental
    circumstances, etc.

    regards,

    Hung Jung
     
    Hung Jung Lu, Nov 14, 2003
    #8
  9. Carlo v. Dango

    Hung Jung Lu Guest

    Related to my other posting, I guess what the original poster wanted
    was getter/setter accessor method, or equivalent, for a particular
    name inside a module.

    Hung Jung
     
    Hung Jung Lu, Nov 14, 2003
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Honne Gowda A
    Replies:
    2
    Views:
    913
    Karl Heinz Buchegger
    Oct 31, 2003
  2. andy6
    Replies:
    2
    Views:
    793
    andy6 via DotNetMonster.com
    Jun 9, 2006
  3. Replies:
    2
    Views:
    970
    Bengt Richter
    Aug 1, 2005
  4. Richard Tobin
    Replies:
    24
    Views:
    825
  5. Bob
    Replies:
    5
    Views:
    289
Loading...

Share This Page