By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,732 Members | 1,397 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,732 IT Pros & Developers. It's quick & easy.

Class attributes, instances and metaclass __getattribute__

P: n/a

Hi all
I noticed something strange here while explaining decorators to someone.
Not any real use code, but I think it's worth mentioning.

When I access a class attribute, on a class with a custom metaclass with
a __getattribute__ method, the method is used when acessing some
attribute directly with the class object, but not when you do it from
the instance.

<code type='prompt'>
>>class M(type):
.... def __getattribute__(cls, attr):
.... print cls, attr
.... return type.__getattribute__(cls, attr)
....
>>class C(object):
.... __metaclass__ = M
....
>>C.x = 'foo'
C.x
<class '__main__.C'x
'foo'
>>o = C()
o.x
'foo'
>>>
</code>
Someone at freenode #python channel involved with python-dev sprint
suggested it might be a bug, worth mentioning... to me it seems like a
decision to avoid some problems with method and descriptors creation,
since someone using metaclasses and custom __getattribute__ at the same
time is asking for trouble, but... I googled for it and tried to find
something on the list but, nothing. From the source it seems like a
generic wrapper is used. What's the real case here ?
Regards,

--
Pedro Werneck
Aug 7 '06 #1
Share this Question
Share on Google+
4 Replies


P: n/a
Pedro Werneck wrote:
When I access a class attribute, on a class with a custom metaclass with
a __getattribute__ method, the method is used when acessing some
attribute directly with the class object, but not when you do it from
the instance.

<code type='prompt'>
>class M(type):
... def __getattribute__(cls, attr):
... print cls, attr
... return type.__getattribute__(cls, attr)
...
>class C(object):
... __metaclass__ = M
...
>C.x = 'foo'
C.x
<class '__main__.C'x
'foo'
>o = C()
o.x
'foo'
>>
</code>
Someone at freenode #python channel involved with python-dev sprint
suggested it might be a bug, worth mentioning... to me it seems like a
decision to avoid some problems with method and descriptors creation,
since someone using metaclasses and custom __getattribute__ at the same
time is asking for trouble, but... I googled for it and tried to find
something on the list but, nothing. From the source it seems like a
generic wrapper is used. What's the real case here ?
Regards,

--
Pedro Werneck
To me, it seems consistent. As said in
http://www-128.ibm.com/developerwork...ary/l-pymeta2/

"""The availability of metaclass attributes is not transitive; in other
words, the attributes of a metaclass are available to its instances,
but not to the instances of the instances. Just this is the main
difference between metaclasses and superclasses."""

Since this happens for real attributes, it looks natural that the same
should
happen for 'virtual' attributes implemented via '__getattr__' or
'__getattribute__'.

Michele Simionato

Aug 8 '06 #2

P: n/a

Hi

On 8 Aug 2006 00:10:39 -0700
"Michele Simionato" <mi***************@gmail.comwrote:
To me, it seems consistent. As said in
http://www-128.ibm.com/developerwork...ary/l-pymeta2/

"""The availability of metaclass attributes is not transitive; in
other words, the attributes of a metaclass are available to its
instances, but not to the instances of the instances. Just this is the
main difference between metaclasses and superclasses."""

Well... I'm not talking about metaclass attributes... that's perfectly
consistent, agreed.

I'm saying that when the class implements a custom __getattribute__,
when you try to access the instance attributes from itself, it uses it.
But if the class is a metaclass, instances of its instances have acess
to the attribute anyway, but don't use the custom __getattribute__ you
implemented.

Like the example I mentioned on the previous mail, or (I think in this
case it's more obvious):
>>class N(type):
.... def __getattribute__(cls, attr):
.... print 'using N.__getattribute for "%s"'%(attr)
.... return type.__getattribute__(cls, attr)
....
>>class M(type):
.... __metaclass__ = N
....
>>class C(object):
.... __metaclass__ = M
....
>>M.x = 'foo'
M.x
using N.__getattribute for "x"
'foo'
>>C.x
'foo'
So, in both cases I have access to the class attribute; but in one case
it's using the bound M.__getattribute__ implemented at the base
metaclass, but not in the other. It was supposed to use it after the
bound 'C.__getattribute__' raises AttributeError as expected, but it
doesn't...

It's inconsistent, but seems a reasonable decision to me since someone
can easily mess with descriptors doing with this... but, someone else
involved with Python dev I talked about thinks it may be a bug.

And, I'm curious anyway... is it possible to customize attribute access
in this case in any other way ? What really happens here ?
>From the typeobject.c source code, seems like when the metaclass
implements __getattribute__, it uses type.__getattribute__ in this case,
but I'm not sure.

Since this happens for real attributes, it looks natural that the same
should happen for 'virtual' attributes implemented via '__getattr__'
or '__getattribute__'.
Well... as I think it's clear now, the case you mentioned is not exactly
what I'm talking about, but it's good you mentioned about 'virtual'
attributes, because in this case we have another problem, it's
inconsistent too and there's no reason for it...
>>class M(type):
.... def __getattr__(cls, attr):
.... if attr == 'x':
.... return 'foo'
....
>>class C(object):
.... __metaclass__ = M
....
>>C.y = 'bar'
C.x
'foo'
>>C.y
'bar'
>>o = C()
>>o.x
....
AttributeError: 'C' object has no attribute 'x'
>>o.y
'bar'
>>>
So... both 'x' and 'y' are class attributes, but 'x' is a virtual
attribute implemented with M.__getattr__. From the instance I have
access to 'y' but not to 'x'.

Regards,

--
Pedro Werneck
Aug 8 '06 #3

P: n/a
Pedro Werneck wrote:
Hi
[snip]
Well... I'm not talking about metaclass attributes... that's perfectly
consistent, agreed.

I'm saying that when the class implements a custom __getattribute__,
when you try to access the instance attributes from itself, it uses it.
But if the class is a metaclass, instances of its instances have acess
to the attribute anyway, but don't use the custom __getattribute__ you
implemented.
Attribute lookup for instances of a class never calls metaclass'
__getattribute__() method. This method is called only when you
access attributes directly on the class.

[snip]
And, I'm curious anyway... is it possible to customize attribute access
in this case in any other way ? What really happens here ?
There are two distinct methods involved in your example; attribute
lookup for classes is controled by metaclass' __getattribute__()
method, while instance attribute lookup is controled by class'
__getattribute__() method.

They are basicaly the same, but they never use ``type(obj).attr`` to
access the class' attributes. The code for these methods would look
something like this in Python:

class Object(object):
"""
Emulates object's and type's behaviour in attribute lookup.
"""

def __getattribute__(self, name):
cls = type(self)

# you normally access this as self.__dict__
try:
dict_descriptor = cls.__dict__['__dict__']
except KeyError:
# uses __slots__ without dict
mydict = {}
else:
mydict = dict_descriptor.__get__(self, cls)

# Can't use cls.name because we would get descriptors
# (methods and similar) that are provided by class'
# metaclass and are not meant to be accessible from
# instances.
classdicts = [c.__dict__ for c in cls.__mro__]

# We have to look in class attributes first, since it can
# be a data descriptor, in which case we have to ignore
# the value in the instance's dict.
for d in classdicts:
if name in d:
classattr = d[name]
break
else:
# None of the classes provides this attribute; perform
# the normal lookup in instance's dict.
try:
return mydict[name]
except KeyError:
# Finally if everything else failed, look for the
# __getattr__ hook.
for d in classdicts:
if '__getattr__' in d:
return d['__getattr__'](self, name)
msg = "%r object has no attribute %r"
raise AttributeError(msg % (cls.__name__, name))

# Check if class' attribute is a descriptor.
if hasattr(classattr, '__get__'):
# If it is a non-data descriptor, then the value in
# instance's dict takes precedence
if not hasattr(classattr, '__set__') and name in mydict:
return mydict[name]
return classattr.__get__(self, cls)

# Finally, look into instance's dict.
return mydict.get(name, classattr)

As you can see, it completely avoids calling metaclass'
__getattribute__()
method. If it wouldn't do that, then the metaclass' attributes would
'leak' to instances of its classes. For example, __name__, __mro__
and mro() are some of the descriptors provided by type to every class,
but they are not accesible through instances of these classes,
and shouldn't be, otherwise they could mask some errors in user's code.

Ziga

Aug 8 '06 #4

P: n/a
On 8 Aug 2006 07:24:54 -0700
"Ziga Seilnacht" <zi************@gmail.comwrote:
[snip]
Well... I'm not talking about metaclass attributes... that's
perfectly consistent, agreed.

I'm saying that when the class implements a custom __getattribute__,
when you try to access the instance attributes from itself, it uses
it. But if the class is a metaclass, instances of its instances have
acess to the attribute anyway, but don't use the custom
__getattribute__ you implemented.

Attribute lookup for instances of a class never calls metaclass'
__getattribute__() method. This method is called only when you
access attributes directly on the class.
Well... thanks for the answer.

As I said on the first mail, I noticed this when I was explaining
descriptors and methods to someone else... I implemented a pure-python
Method class to show him exactly how it works.

But, since their __get__ call is available at the class too, my first
thought was that it was implemented at the metaclass __getattribute__,
and when an instance tries to get a class attribute it would fail on its
own __getattribute__, use the bound method at its class and make the
call.

After implementing a test metaclass I noticed it doesn't work this way,
and even if it's a bit inconsistent (especially in the case of 'virtual'
attributes), it seemed to me the reasonable thing to do, exactly for
what you mentioned on your code... someone could easily break a lot of
stuff doing it the wrong way, instead if not using __dict__.

I mailed the list because someone else thought it might be a bug and I
was in doubt... now it's clear it was the right thing to do.
Regards,

--
Pedro Werneck
Aug 8 '06 #5

This discussion thread is closed

Replies have been disabled for this discussion.