Python Macros

[Alex Martelli]

Thanks (again!). Another dumb mistake. I have mixed up __get__attr,
descriptors, and __getattribute__ in my head, all at once, and messed
up the concepts. Too much reading and too little practice do it .

You're welcome! Yep, getting some practice would help...
infrastructure's a cool thing, but getting direct experience of how to
do real-life apps helps you grasp the infrastructure better, too.

The funny thing is that the code worked as written, at least for my
small test case, because it failed to find the dog.fetch method
anyway.

Heh, yes, you weren't looking for dog.keys or dog.update, say;-).


Alex

 

[Josiah Carlson]

This is not true.

Proof by counterexample: I sometimes do.

All right, then I will make the claim that it is not Pythonic to do so,
because I have never heard Guido do such a thing.

- Josiah

 

[Arich Chanachai]

In ObjC it would be send the message y with value z to object X
Say X doesn't know what to do with y
specified in X's code are instruction that tell it what object to pass
the message y to...say...U for example

So the message has been passed and basically translates into U.y(z) or
in ObjC [U y:z]

You mean some refinement of this sort of thing:

class X(object):

a = "lives in X"

def __getattr__(self, name):
return getattr(U,name)

class U(object):

b = "lives in Y"

x = X()
print x.a
print x.b

?

Sure, but what if I dynamically (at runtime) extend X to include
variable b. Will it then print X.b or still U.b?

 

[Jeff Shannon]

<SNIP>

Sure, but what if I dynamically (at runtime) extend X to include
variable b. Will it then print X.b or still U.b?

In this case, as I understand it, adding an attribute b to either x (the
instance) or X (the class) will cause x.b to resolve to the new
attribute, and *not* to U.b -- attributes are dynamically looked up each
time they are used, and __getattr__() is called only when the standard
lookup methods (instance, class, superclass, ...) fail.

Jeff Shannon
Technician/Programmer
Credit International

 

[Arich Chanachai]

In this case, as I understand it, adding an attribute b to either x
(the instance) or X (the class) will cause x.b to resolve to the new
attribute, and *not* to U.b -- attributes are dynamically looked up
each time they are used, and __getattr__() is called only when the
standard lookup methods (instance, class, superclass, ...) fail.
Jeff Shannon
Technician/Programmer
Credit International

Cool. This seems then to have the same functionality as ObjC messages.
I am beginning to like Python more and more.

 

[Jacek Generowicz]

Sure, but what if I dynamically (at runtime) extend X to include
variable b. Will it then print X.b or still U.b?

Did you try it?

__getattr__ only gets invoked if the attribute is not found in the
instance, class and superclass dictionaries.

 

[Jacek Generowicz]

All right, then I will make the claim that it is not Pythonic to do so,
because I have never heard Guido do such a thing.

Aaaah, proof by ignorance: I am not aware of it, therefore it isn't so.


BTW, I _really_ meant the in the previous post. There is really no
(serious) point in taking this any further, is there ?

 

[Just]

redundant: hasattr(self, attr) will ALWAYS be false here, or else
__getattr__ wouldn't have been entered in the first place.

Worse, hasattr(self, attr) will invoke self.__getattr__()...

Just

 

[Greg Ewing]

An _implementation_ difference, and in fact a pretty minor detail too,
not any real _language_ difference.

I don't entirely agree with that. In Python, method calling is
not a primitive syntactic construct, it's a combination of two
others, attribute selection and calling. In Smalltalk, on the
other hand, it is a single construct, and there is no construct
for doing just the lookup part (there might be a way of doing
it, but there's no special syntax for it).

It might not be a very *important* difference, but it is a
language difference, and I think it influences how one thinks
about some problems.