class instance has `__dict__`

[tharvik]

class A:
    pass
A().__dict__

is a valid python3 statement but mypy (more a typeshed issue I guess) gives me

file:4: error: "A" has no attribute "__dict__"

So I modified added, in object, __dict__ = ... # type: Dict[str, Any] to stdlib/3/builtins.pyi which indeed make it warning-less.

But, it is wrong, as

object().__dict__

fail with an AttributeError.

Is there a better place to put this __dict__? Or is it a mypy issue?

[JukkaL]

I think that instances of built-in / extension types don't have __dict__. Currently mypy doesn't know which objects are built-in and which aren't. A general solution will likely have to involve typeshed -- we'd have to add some way of tagging built-in classes. However, I believe that this can vary between Python implementations, so perhaps we should just ignore this, or perhaps teach mypy about some of the most common built-in types.

For now, adding __dict__ to object seems reasonable to me, even if accessing the attribute may fail at runtime.

[gvanrossum]

I think this may be undocumented but it's not meant to be varying by Python implementation -- the rule is that classes defined in extension modules don't have __dict__ but anything defined using a class statement has a __dict__ unless it defines __slots__ and all its base classes also don't have a __dict__.

Hm, that actually suggests a way to mark classes that doesn't require anything new in typing.py: we could add __slots__ to all classes that are supposed to be builtin (e.g. object, str, int) and mypy could implement a new rule that implicitly adds __dict__: Dict[str, Any] to any class definition that doesn't have __slots__.

@JukkaL If you agree with that proposal can you add a mypy issue for this?

[gvanrossum]

(Keeping this open as a reminder that we should really fix this better.)

[JukkaL]

@gvanrossum Sounds good, I created a mypy issue (I just quoted you).

[kaddkaka]

Any updates to this issue?