This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: __getattr__ and metaclasses
Type: Stage:
Components: Interpreter Core Versions:
Status: closed Resolution: duplicate
Dependencies: Superseder:
Assigned To: Nosy List: georg.brandl, grodr, michele_s, mwh
Priority: normal Keywords:

Created on 2003-08-15 14:18 by grodr, last changed 2022-04-10 16:10 by admin. This issue is now closed.

Messages (4)
msg17782 - (view) Author: Gonçalo Rodrigues (grodr) Date: 2003-08-15 14:18
This came out from a thread in comp.lang.python: Here’s 
the reference:

Consider the following example (provided by M. 

>>> class M(type):
... 	def __getattr__(self, name):
... 		if name == '__iter__':
... 			return lambda self: iter([])
>>> class C(object):
... 	__metaclass__ = M
>>> C.__iter__
<function <lambda> at 0x0110E8F0>
>>> c = C()
>>> iter(c)
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
TypeError: iteration over non-sequence

This means that the iterator machinery does not check 
__getattr__ (or __getattribute__ for that matter – I 
have made the test). The Language Reference says:

“A class can implement certain operations that are 
invoked by special syntax (such as arithmetic operations 
or subscripting and slicing) by defining methods with 
special names.”

Which does not throw much light on the matter at hand. 
So there are two ways we can view the above:

(A) It’s a bug.

This is the one I favour ;-). Arguing by contradiction, 
not being considered a bug means that there is a very 
special distinction being made when it comes to 
attribute lookup of special names. 

I tend to follow the Gang of Four’s main 
injunction “Prefer composition to inheritance”. 
Composition is great in Python precisely because of the 
__getattr__ hook. Not being able to use __getattr__ in 
metaclasses to trap special names surely hampers that 
role somewhat.

(B) It’s not a bug.

Then at least I think that the documentation should be 
worded more accurately. Quoting A. Martelli on the same 

“__getattr__ is not a BINDING of the special method, 
though it may be considered a DEFINITION of it, which is 
why the current phrase in the Language Reference is not 
100% correct and complete -- only 99.44%, and I agree 
that the remaining 0.56% _is_ a delicate defect in the 

With my best regards,
G. Rodrigues
msg17783 - (view) Author: Michele Simionato (michele_s) Date: 2003-08-21 10:16
Logged In: YES 

Two comments:

1. The credit for discovering this "issue" goes to Bjorn
Pettersen, not to me.

2. The issue is NOT with metaclasses, the title should
be "special methods and __getattr__"

The metaclass works perfectly fine and


works. The problem is with the "iter" builtin, since

iter(x) DOES NOT call X.__iter__(x).

Same with str, len, etc.

Metaclasses are not guilty here!

msg17784 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2004-03-01 11:12
Logged In: YES 

> Metaclasses are not guilty here!

It's more complicated than that.

iter(o) does (roughly)


At class definition time, if the class defines __iter__, a
wrapper for it is stuffed into the type's tp_iter slot.  If
it doesn't, NULL is placed there instead.

What *could* be done is, if the *meta*class defines
__getattr__ or __getattribute__, all the tp_ slots could be
filled with a special wrapper that calls the generic
attribute getter.  But that would be quite a coding effort,
and these classes would have pretty atrocious performance.

And making this work when you assign to __getattribute__ on
the metaclass would be a truly crazy piece of code.

Or the docs could note this limitation.
msg17785 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2005-10-01 13:43
Logged In: YES 

Duplicate of #729913.
Date User Action Args
2022-04-10 16:10:39adminsetgithub: 39069
2003-08-15 14:18:25grodrcreate