[Python-Dev] inconsistent __abstractmethods__ behavior; lack of documentation
Hi, while playing with abstract base classes and looking at their implementation, I've stumbled across the following issue. With Python 3.2, the script class Foo(object): __abstractmethods__ = ['boo'] class Bar(object): pass Bar.__abstractmethods__ = ['boo'] f = Foo() b = Bar() produces the following output Traceback (most recent call last): File "/home/cwg/test2.py", line 9, in b = Bar() TypeError: Can't instantiate abstract class Bar with abstract methods buzz This seems to violate PEP 3119: it is not mentioned there that setting the __abstractmethods__ attribute already during class definition (as in "Foo") should have no effect. I think this happens because CPython uses the Py_TPFLAGS_IS_ABSTRACT flag to check whether a class is abstract. Apparently, this flag is not set when the dictionary of the class contains __abstractmethods__ already upon creation. As a second issue, the special __abstractmethods__ attribute (which is a feature of the interpreter) is not mentioned anywhere in the documentation. If these are confirmed to be bugs, I can enter them into the issue tracker. Christoph ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] inconsistent __abstractmethods__ behavior; lack of documentation
Christoph, Do you realize that __xxx__ names can have any semantics they darn well please? If a particular __xxx__ name (or some aspect of it) is undocumented that's not a bug (not even a doc bug), it just means "hands off". That said, there may well be a bug, but it would be in the behavior of those things that *are* documented. --Guido On Sat, Aug 6, 2011 at 7:55 AM, Christoph Groth wrote: > Hi, > > while playing with abstract base classes and looking at their > implementation, I've stumbled across the following issue. With Python > 3.2, the script > > class Foo(object): > __abstractmethods__ = ['boo'] > class Bar(object): > pass > Bar.__abstractmethods__ = ['boo'] > f = Foo() > b = Bar() > > produces the following output > > Traceback (most recent call last): > File "/home/cwg/test2.py", line 9, in > b = Bar() > TypeError: Can't instantiate abstract class Bar with abstract methods buzz > > This seems to violate PEP 3119: it is not mentioned there that setting > the __abstractmethods__ attribute already during class definition (as in > "Foo") should have no effect. > > I think this happens because CPython uses the Py_TPFLAGS_IS_ABSTRACT > flag to check whether a class is abstract. Apparently, this flag is not > set when the dictionary of the class contains __abstractmethods__ > already upon creation. > > As a second issue, the special __abstractmethods__ attribute (which is a > feature of the interpreter) is not mentioned anywhere in the > documentation. > > If these are confirmed to be bugs, I can enter them into the issue > tracker. > > Christoph > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] inconsistent __abstractmethods__ behavior; lack of documentation
Guido, thanks for the quick reply! Of course I am aware that __xxx__ names are special. But I was assuming that the features of a python interpreter which are necessary to execute the pure python modules of the standard library are supposed to be documented. Christoph ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] inconsistent __abstractmethods__ behavior; lack of documentation
On 8/6/2011 8:29 AM, Guido van Rossum wrote: Do you realize that __xxx__ names can have any semantics they darn well please? That does not seem to be to be the issue Cristoff raised. If a particular __xxx__ name (or some aspect of it) is undocumented that's not a bug (not even a doc bug), it just means "hands off". "__abstractmethods__" is used in the stdlib at least in abc.py: 95 class ABCMeta(type): ... 116 def __new__(mcls, name, bases, namespace): ... 123 for name in getattr(base, "__abstractmethods__", set()): 124 value = getattr(cls, name, None) 125 if getattr(value, "__isabstractmethod__", False): 126 abstracts.add(name) 127 cls.__abstractmethods__ = frozenset(abstracts) Since this module implements a PEP (3119) and is not marked as CPython specific, it should run correctly on all implementations. So implementors need to know what the above means. ( The doc to abc.py invites readers to read this code: **Source code:** :source:`Lib/abc.py` For both reasons, this attribute appears to be part of Python rather than being private to CPython. If so, the special name *should* be documented somewhere. If it should *never* be used anywhere else (which I suspect after seeing that it is not used in numbers.py), that could be said. "__abstractmethods__: A special attribute used within ABCmeta.__new__ that should never be used anywhere else as is has a special-case effect for this one use." The problem with intentionally completely not documenting names publicly accessible in the stdlib code or from the interactive interpreter is that the non-documentation is not documented, and so the issue of documentation will repeatedly arise. The special names section of 'data model' could have a subsection for such. "The following special names are not documented as to their meaning as users should ignore them." or some such. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
