conceiling function calls..

[Carlo v. Dango]

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

 

[Alex Martelli]

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

 

[Carlo v. Dango]

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

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..

 

[Gonçalo Rodrigues]

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

 

[Alex Martelli]

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.

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.

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

 

[Emile van Sebille]

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.

 

[Alex Martelli]

Gonçalo Rodrigues:

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

 

[Hung Jung Lu]

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]

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