when declaring a abstract base class with an abstract property or method
and subclassing from dict, the class is instantiable (instanceable?).

>>> import abc
>>> class A(object):
...     __metaclass__ = abc.ABCMeta
...     @abc.abstractproperty
...     def abstract(self): return True
... 
>>> a = A()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Can't instantiate abstract class A with abstract methods abstract
>>> 
>>> class A2(dict):
...     __metaclass__ = abc.ABCMeta
...     @abc.abstractproperty
...     def abstract(self): return True
... 
>>> a2 = A2()
>>> 


although, when using the dict definition from __builtin__.pi directly,
the abc behaves like expected. but this may be a bug in the
c-implementation from dict.

platform:
Python 2.6.2 (r262:71600, Apr 25 2009, 21:56:41) 
[GCC 4.3.2] on linux2

Also happens with other builtin types such as tuple. It's probably
related to the way subclasses of those types are instantiated, bypassing
the normal metaclass mechanism.

I presume you claim the dict example to be a bug in relation to "A class
that has a metaclass derived from ABCMeta cannot be instantiated unless
all of its abstract methods and properties are overridden."

There is the same difference with @abstractproperty
Windows, 3.0.1

class C(metaclass=abc.ABCMeta):
	@abc.abstractmethod
	def f(self): return True

class C2(dict,metaclass=abc.ABCMeta):
	@abc.abstractmethod
	def f(self): return True

c2=C2()
print(c2.f())

c=C()
# prints
True
...
TypeError: Can't instantiate abstract class C with abstract methods f

I think, that the reason is that, object.__new__ checks, if the class is instantiable (object_new in Objects/typeobject.c ). dict.__new__ (and tuple.__new__, and I guess the __new__ method of other built-in types) doesn't call object.__new__, but user defined types typically either doesn't have a __new__, or call object.__new__ from it (directly or with super).

This patch fixes the problem by moving the check from object_new to PyType_GenericAlloc. The check is very cheap, so this should not be an issue.

Anyone has any thoughts on this?

IIRC, classes weren't supposed to be able inherit from two classes that had different metaclasses (since differing metaclasses don't necessarily play well with one another).

They are, when there's a most specific metaclass -- the one which is a subclass of all others (described here http://www.python.org/download/releases/2.2.3/descrintro/#metaclasses, implemented here http://hg.python.org/cpython/file/ab162f925761/Objects/typeobject.c#l1956). Since ABCMeta is a subclass of type this holds.

Also, in the original example there's no multiple inheritance at all.

I think subclassing builtin types and making it abstract is rare. And when there is a need, we can mimic this in application level (this may also apply to types having custom __new__):

In [2]: class CustomDict(dict, metaclass=abc.ABCMeta):
   ...:     def __new__(cls, *args, **kwargs):
   ...:         if getattr(cls, '__abstractmethods__', None):
   ...:             raise TypeError
   ...:         return super().__new__(cls, *args, **kwargs)
   ...:     @abc.abstractmethod
   ...:     def f(self):
   ...:         pass

Adding the abstract class checking in tp_alloc or builtin types' tp_new maybe degrade performance.

Is it necessary to add this support?

Honestly let's just forget about this.

Wait, really? My report came out of a real bug that I had in my system and shipped to my users; it wasn't academic or contrived at all.

Where did you report that? I don't see your name on this bug -- it has a patch that's been unapplied for 5 years, so I doubt it's very important.

Oh sorry. I received the emails in a strange order. I guess it can stay open.

My apologies, I added Nathaniel to nosy here when I closed the duplicate, but forgot to add a link to the closed issue: issue 28537.

Closed issue 31127 as a duplicate of this one.

Closed #35958 as a duplicate of this issue (and updated the title, since clearly the problem is not specific to dict).

Patch probably needs to be rebased/rewritten against latest trunk (given it dates from Mercurial days).

versions: + Python 3.5, Python 3.6, Python 3.7, Python 3.8
stage: patch review

nosy: + eltoder
messages: + msg133440

keywords: + patch

versions: + Python 3.3, - Python 2.6

messages: + msg87576