Should we make built-in classes special?

[JukkaL]

Mypy allows marking some classes as 'built-in' in stubs, since these classes (C classes in CPython) are semantically different from ordinary classes. For example, multiple inheritance is different:

class X(int, str):  # multiple bases have instance lay-out conflict
    pass

Mypy uses the typing.builtinclass decorator for this. Here's a simplified example from mypy stubs for builtins:

from typing import builtinclass

@builtinclass
class str(...):
    ...

Here are some questions:

1. Should we define a way of annotating a class as a built-in class?
2. Multiple inheritance is possible from some sets of built-in classes. Do we need to able to define precisely when a built-in class has an instance layout that is different from the base class?
3. What's the best term for this -- should we call them built-in classes, as 3rd part modules can also define them?

[gvanrossum]

It sound reasonable to have something for this. It should only be used in stubs I think. I don't think we should try to guess which built-in types are compatible for MI (nobody uses this anyway). Maybe name it extension_type?

[JukkaL]

We (me, Mark Shannon and Andrey Vlasovskikh) discussed this yesterday and didn't consider this as an essential feature.

[JukkaL]

Should this be postponed? Mypy no longer uses the @builtinclass decorator in stubs (though the implementation is still there).

[gvanrossum]

I'm closing this issue. We decided that it would be better to add understanding of __slots__ to mypy, including how it determines whether the new class has a __dict__. See python/mypy#1325.