[Python-Dev] inconsistent __abstractmethods__ behavior; lack of documentation

[Guido van Rossum]

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 <module>
>    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
> 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)