gh-104549: Set __module__ on TypeAliasType

[JelleZijlstra]

• Issue: TypeAliasType should have a __module__ #104549

[AlexWaygood]

I can't review the C code, but I much prefer this behaviour to the behaviour on main! Manual testing also didn't reveal any bugs.

Maybe it's also worth testing that TypeAliasType.__module__ == 'typing'? (I.e., accessing __module__ on the class itself rather than instances of the class.) That's the only comment I have!

[Eclips4]

One nit about tests: may it be useful to define a type alias in another module, and check something like assertEqual(x.Alias.__module__, x) where x is a some module.
Otherwise, C code looks fine, but I have one question. Should typealias_module be able to return None, and should it be tested?

[JelleZijlstra]

@AlexWaygood unfortunately this no longer works, I get

test test_type_aliases failed -- Traceback (most recent call last):
  File "/Users/jelle/py/cpython/Lib/test/test_type_aliases.py", line 211, in test_module
    self.assertEqual(TypeAliasType.__module__, "typing")
AssertionError: <attribute '__module__' of 'typing.TypeAliasType' objects> != 'typing'

This seems to be an inescapable consequence of how heap types work (

cpython/Objects/typeobject.c

Line 1045 in 1b5a2b0

if (type->tp_flags & Py_TPFLAGS_HEAPTYPE) {

), so not sure how to get around it.

@Eclips4 good call about tests in another module, I'll add some.

As for the module being NULL, apparently that can happen in various exotic situations where there is no calling function or that function has no module. Not 100% sure how to reproduce that.

[AlexWaygood]

This seems to be an inescapable consequence of how heap types work

That's a shame :( This inconsistency is a little unfortunate:

>>> from typing import TypeAliasType, TypeVar
>>> TypeAliasType.__module__
<attribute '__module__' of 'typing.TypeAliasType' objects>
>>> TypeVar.__module__
'typing'
>>> type T = int | str
>>> T.__module__
'__main__'
>>> TypeVar("T").__module__
'__main__'

[AlexWaygood]

That's a shame :( This inconsistency is a little unfortunate:

(But if there's no way of resolving that, then this is still definitely an improvement on the status quo :)

[JelleZijlstra]

Possible solutions:

• Make TypeAliasType into a static type. I think there is no strong reason for it to be a heap type, unlike with Generic and TypeVar; I made it a heap type for consistency with the other types in the file.
• Give it a TP_MANAGED_DICT and put the __module__ in the dict; this is how TypeVar works, but it feels wasteful, and I don't see a need to allow setting arbitrary attributes on type aliases.

[AlexWaygood]

• Give it a TP_MANAGED_DICT and put the __module__ in the dict; this is how TypeVar works, but it feels wasteful, and I don't see a need to allow setting arbitrary attributes on type aliases.

Yeah, I agree that that allowing arbitrary setting of attributes seems unnecessary

[JelleZijlstra]

oops, messed up the merge

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @carljm for commit 7898e78 🤖

If you want to schedule another build, you need to add the 🔨 test-with-refleak-buildbots label again.

[carljm]

Assuming the refleak buildbots are happy, this LGTM.