[Python-Dev] inconsistent abstractmethods behavior; lack of documentation (original) (raw)

Guido van Rossum guido at python.org
Sat Aug 6 14:29:09 CEST 2011


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 <cwg at falma.de> 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 PyTPFLAGSISABSTRACT 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 Python-Dev at python.org 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)



More information about the Python-Dev mailing list