Improve handling of attribute access on class objects

[AlexWaygood]

Fixes #14056

#14056 was originally reported as a mypyc issue (because that's how it presented itself to the user), but the underlying bug is really a bug to do with how mypy understands metaclasses. On mypy master:

class Meta(type):
    bar: str

class Foo(metaclass=Meta):
    bar: int

reveal_type(Foo().bar)  # Revealed type is int (correct!)
reveal_type(Foo.bar)  # Revealed type is int, but should be str

This PR fixes that incorrect behaviour.

Since this is really a mypy bug rather than a mypyc bug, I haven't added a mypyc test, but I'm happy to if that would be useful. (I'll need some guidance as to exactly where it should go -- I don't know much about mypyc internals!)

[AlexWaygood]

and not hook was required here, or this test started to fail:

mypy/test-data/unit/check-custom-plugin.test

Lines 974 to 990 in 89469ac

	[case testClassAttrPluginMetaclassRegularBase]
	# flags: --config-file tmp/mypy.ini
	from typing import Any, Type
	class M(type):
	attr = 'test'
	class B:
	attr = None
	class Cls(B, metaclass=M):
	pass
	reveal_type(Cls.attr) # N: Revealed type is "builtins.int"
	[file mypy.ini]
	\[mypy]
	plugins=<ROOT>/test-data/unit/plugins/class_attr_hook.py

[AlexWaygood]

This test needed to be altered slightly, as with this change, mypy starts inferring the correct type of X.__annotations__ according to the fixture that this test uses:

mypy/test-data/unit/fixtures/dict.pyi

Lines 16 to 17 in 89469ac

	class type:
	__annotations__: Mapping[str, object]

[AlexWaygood]

You could argue that bar and spam here violate LSP (since setting a class variable on a class is ~basically the same as setting an instance variable on a metaclass). This PR doesn't change the behaviour there, however: mypy emits no errors here on master, and doesn't with this PR applied either.

[AlexWaygood]

Mypy_primer analysis:

• The discord one is obviously just an existing error message changing slightly
• The steam one is here: https://github.com/Gobot1234/steam.py/blob/e5c90d3321180c499708d51392d6fcdbef41c0bc/steam/id.py#L122. I'm not quite sure why mypy previously thought the ._member_map_ access was ambiguous, but it seems like an improvement that this error is going away, anyway. For reference, here's a link to typeshed's stub for enum.EnumMeta._member_map_: https://github.com/python/typeshed/blob/34018d6a2c9833de7c5718a70b5346245f583a73/stdlib/enum.pyi#L154
• The pandera hit is here: https://github.com/unionai-oss/pandera/blob/a0d95c7927d5f222dc3664e411a121499b6ebbdd/pandera/api/pandas/model.py#L414-L418. Mypy seems to struggle a little more with inference when it comes to <dict_obj>.update(<mapping_proxy_obj>) as opposed to <dict_object>.update(<other_dict_obj>), for some reason.

[JelleZijlstra]

Looks good, but this isn't an area of mypy that I'm familiar with.

Maybe a test case involving a generic metaclass would be helpful.

[AlexWaygood]

Thanks for the review, appreciate it!

Maybe a test case involving a generic metaclass would be helpful.

The new behaviour doesn't work with generic metaclasses. But I don't think that's really anything to do with this PR: mypy in general hates generic metaclasses:

from typing import TypeVar, Generic

T = TypeVar("T")

class Meta(type, Generic[T]):
    attr: T

class Foo(metaclass=Meta[int]): ...  # error: Dynamic metaclass not supported for "Foo"  [misc]

https://mypy-play.net/?mypy=latest&python=3.11&gist=f360b7b7366c4618ac0b6d79f0e404b9

Mypy emits the same "dynamic metaclasses not supported" error with this PR, so I think users will have fair warning that what they're trying to do isn't supported, if they do something like that. I'm not sure if a test would be helpful here or not, since I guess ideally mypy would support generic metaclasses, and I don't want to assert incorrect or undesirable behaviour in a test.

[ikonst]

I tried to reproduce the steam error but couldn't yet. Here's where I stopped: https://mypy-play.net/?mypy=latest&python=3.11&gist=fdd3d72f616b8ce786c6c7f8bc2a79fd

[github-actions]

Diff from mypy_primer, showing the effect of this PR on open source code:

steam.py (https://github.com/Gobot1234/steam.py)
- steam/id.py:123: error: Access to generic instance variables via class is ambiguous  [misc]

pandera (https://github.com/pandera-dev/pandera)
+ pandera/api/pandas/model.py:416: error: Need type annotation for "attrs" (hint: "attrs: Dict[<type>, <type>] = ...")  [var-annotated]

discord.py (https://github.com/Rapptz/discord.py)
- discord/ext/commands/cog.py:358: error: Incompatible types in assignment (expression has type "Group | discord.app_commands.commands.Command[Cog, [VarArg(Any), KwArg(Any)], Any]", variable has type "discord.ext.commands.core.Command[Self, [VarArg(Any), KwArg(Any)], Any]")  [assignment]
+ discord/ext/commands/cog.py:358: error: Incompatible types in assignment (expression has type "Group | discord.app_commands.commands.Command[Any, [VarArg(Any), KwArg(Any)], Any]", variable has type "discord.ext.commands.core.Command[Self, [VarArg(Any), KwArg(Any)], Any]")  [assignment]

[AlexWaygood]

Thanks @ilevkivskyi and @JelleZijlstra!