classification
Title: non-Pythonic fate of __abstractmethods__
Type: Stage:
Components: Versions: Python 3.2
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: benjamin.peterson Nosy List: Trundle, Yaroslav.Halchenko, benjamin.peterson, daniel.urban
Priority: normal Keywords:

Created on 2010-10-01 13:47 by Yaroslav.Halchenko, last changed 2010-10-24 17:34 by eric.araujo. This issue is now closed.

Messages (5)
msg117798 - (view) Author: Yaroslav Halchenko (Yaroslav.Halchenko) Date: 2010-10-01 13:47
We ran into this while generating documentation for our project (PyMVPA) with recent sphinx and python2.6 (fine with 2.5, failed for 2.6, 2.7, 3.1), which relies on traversing all attributes given by "dir(obj)", BUT apparently __abstractmethods__ becomes very special -- it is given by "dir(obj)" since it is present in obj.__class__, but getattr(obj, "__abstractmethods__") fails for classes derived from type.  E.g. following sample demonstrates it:

print("in type's dir" , '__abstractmethods__' in dir(type))
print(type.__abstractmethods__)

class type3(type):
    pass

print("in type3's dir" , '__abstractmethods__' in dir(type3))
print(type3.__abstractmethods__)


results in output:

$> python2.6 trash/type_subclass.py
("in type's dir", True)
<attribute '__abstractmethods__' of 'type' objects>
("in type3's dir", True)
Traceback (most recent call last):
  File "trash/type_subclass.py", line 9, in <module>
    print(type3.__abstractmethods__)
AttributeError: __abstractmethods__


$> python3.1 trash/type_subclass.py 
in type's dir True
<attribute '__abstractmethods__' of 'type' objects>
in type3's dir True
Traceback (most recent call last):
  File "trash/type_subclass.py", line 9, in <module>
    print(type3.__abstractmethods__)
AttributeError: __abstractmethods__


And that seems to be the only attribute behaving like that (others are fine and accessible).  Some people even seems to provide workarounds already, e.g.:
http://bitbucket.org/DasIch/bpython-colorful/src/19bb4cb0a65d/bpython/repl.py
when __abstractmethods__ is accessed only for the subclasses of ABCmeta ...

so, is it a bug or a feature (so we have to take care about it in all traversals of attributes given by dir())? ;)
msg117814 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2010-10-01 16:23
I see the problem; will consider/fix later today hopefully.
msg117853 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2010-10-02 00:05
As of r85154, type.__abstractmethods__ now raises an AttributeError, too.
msg117861 - (view) Author: Yaroslav Halchenko (Yaroslav.Halchenko) Date: 2010-10-02 04:45
yikes... surprising resolution -- I expected that fix would either makes __abstractmethods__ accessible in derived "type"s or becomes absent from output of dir() -- but none of those has happened.  Now we ended up with a consistent non-Pythonic fate of __abstractmethods__ listed in output of dir() but not accessible.  is that a feature?
msg117885 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2010-10-02 16:56
2010/10/1 Yaroslav Halchenko <report@bugs.python.org>:
>
> Yaroslav Halchenko <yarikoptic@gmail.com> added the comment:
>
> yikes... surprising resolution -- I expected that fix would either makes __abstractmethods__ accessible in derived "type"s or becomes absent from output of dir() -- but none of those has happened.  Now we ended up with a consistent non-Pythonic fate of __abstractmethods__ listed in output of dir() but not accessible.  is that a feature?

type has no __abstractmethods__, so it should raise an AttributeError.
Note descriptors are allowed to raise AttributeError even if they're
in dir().
History
Date User Action Args
2010-10-24 17:34:12eric.araujosetversions: + Python 3.2, - Python 2.6
2010-10-02 16:56:23benjamin.petersonsetmessages: + msg117885
2010-10-02 04:45:22Yaroslav.Halchenkosetmessages: + msg117861
2010-10-02 00:05:23benjamin.petersonsetstatus: open -> closed
resolution: fixed
messages: + msg117853
2010-10-01 17:00:38daniel.urbansetnosy: + daniel.urban
2010-10-01 16:23:57benjamin.petersonsetassignee: benjamin.peterson
messages: + msg117814
2010-10-01 14:54:02r.david.murraysetnosy: + benjamin.peterson
2010-10-01 14:09:58Trundlesetnosy: + Trundle
2010-10-01 13:47:31Yaroslav.Halchenkocreate