You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Unexpected name mangling behavior with generics #119311
This raises NameError: name '_Bar__Foo' is not defined. However, removing the [T] results in the error disappearing. This suggests that the name mangling behavior is inconsistent when generics are involved. This behavior seems to be a bug, as it would be expected for the name mangling to either always occur or never occur, regardless of whether generics are used.
I agree this is a bug. We apply name mangling to all names that appear in the type parameter scope for the generic class (and also to all code after it, which is a separate bug: #119395). In the example, this means __Foo in the bases gets mangled to _Bar__Foo.
We could instead not do any mangling in the type parameter scope. That would fix this bug and simplify the code. However, it would break cases like this:
class X[__T]:
def foo(self, x: __T): ...
If we didn't do mangling in the type parameter scope, the second use of __T would get mangled, but the first one wouldn't, so the second use of __T would fail to resolve.
Fortunately, the set of names that can appear in a type parameter scope is very limited. I think it should be possible to mangle only the type parameter names defined in the scope but nothing else. This would make both my example and the OP's example work, but it adds some complexity to the symtable.
Activity
JelleZijlstra commentedon May 22, 2024
I agree this is a bug. We apply name mangling to all names that appear in the type parameter scope for the generic class (and also to all code after it, which is a separate bug: #119395). In the example, this means
__Fooin the bases gets mangled to_Bar__Foo.We could instead not do any mangling in the type parameter scope. That would fix this bug and simplify the code. However, it would break cases like this:
If we didn't do mangling in the type parameter scope, the second use of
__Twould get mangled, but the first one wouldn't, so the second use of__Twould fail to resolve.Fortunately, the set of names that can appear in a type parameter scope is very limited. I think it should be possible to mangle only the type parameter names defined in the scope but nothing else. This would make both my example and the OP's example work, but it adds some complexity to the symtable.
pythongh-119311: Fix name mangling with PEP 695 generic classes
gh-119311: Fix name mangling with PEP 695 generic classes (#119464)
pythongh-119311: Fix name mangling with PEP 695 generic classes (pyth…
[3.12] pythongh-119311: Fix name mangling with PEP 695 generic classes (
[3.13] gh-119311: Fix name mangling with PEP 695 generic classes (#11…
[3.12] gh-119311: Fix name mangling with PEP 695 generic classes (#11…
pythongh-119311: Fix name mangling with PEP 695 generic classes (pyth…
gh-119311: Add missing magic number (3571) for 3.13.0b1 (#125771)
pythongh-119311: Add missing magic number (3571) for 3.13.0b1 (python…