Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

non-Pythonic fate of __abstractmethods__ #54215

Closed
YaroslavHalchenko mannequin opened this issue Oct 1, 2010 · 5 comments
Closed

non-Pythonic fate of __abstractmethods__ #54215

YaroslavHalchenko mannequin opened this issue Oct 1, 2010 · 5 comments
Assignees

Comments

@YaroslavHalchenko
Copy link
Mannequin

YaroslavHalchenko mannequin commented Oct 1, 2010

BPO 10006
Nosy @benjaminp, @Trundle, @durban

Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

Show more details

GitHub fields:

assignee = 'https://github.com/benjaminp'
closed_at = <Date 2010-10-02.00:05:23.953>
created_at = <Date 2010-10-01.13:47:31.944>
labels = []
title = 'non-Pythonic fate of __abstractmethods__'
updated_at = <Date 2010-10-24.17:34:12.899>
user = 'https://bugs.python.org/YaroslavHalchenko'

bugs.python.org fields:

activity = <Date 2010-10-24.17:34:12.899>
actor = 'eric.araujo'
assignee = 'benjamin.peterson'
closed = True
closed_date = <Date 2010-10-02.00:05:23.953>
closer = 'benjamin.peterson'
components = []
creation = <Date 2010-10-01.13:47:31.944>
creator = 'Yaroslav.Halchenko'
dependencies = []
files = []
hgrepos = []
issue_num = 10006
keywords = []
message_count = 5.0
messages = ['117798', '117814', '117853', '117861', '117885']
nosy_count = 4.0
nosy_names = ['benjamin.peterson', 'Trundle', 'daniel.urban', 'Yaroslav.Halchenko']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue10006'
versions = ['Python 3.2']

@YaroslavHalchenko
Copy link
Mannequin Author

YaroslavHalchenko mannequin commented Oct 1, 2010

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())? ;)

@benjaminp
Copy link
Contributor

I see the problem; will consider/fix later today hopefully.

@benjaminp benjaminp self-assigned this Oct 1, 2010
@benjaminp
Copy link
Contributor

As of r85154, type.__abstractmethods__ now raises an AttributeError, too.

@YaroslavHalchenko
Copy link
Mannequin Author

YaroslavHalchenko mannequin commented Oct 2, 2010

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?

@benjaminp
Copy link
Contributor

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

@ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant