(Re-)Make `typing.Generic.__orig_class__` accessible in `__init__`

[XieJiSS]

Bug report

Bug description:

baltus-atomicrules observe that when executing __init__ in a Generic class, the value of __orig_class__ is available in version 3.6 but not in 3.7. And others found that this is still the case from 3.8 to 3.12. To be specific, mitar reproduced on 3.8 to 3.10, LostInDarkMath reproduced on 3.11, and I reproduced on 3.12.

baltus-atomicrules attached a simple example that defines a Generic class and then accesses __orig_class__ in the associated __init__ method.

Simple.py.txt

N = TypeVar('N')
class ZZ(Generic[N]):
    def __init__(self):
        print("__orig_class__ is: ", self.__orig_class__)

In 3.6, this code runs fine:

In [42]: import Simple
In [51]: a = Simple.ZZ[int]
In [56]: b = a()
__orig_class__ is:  Simple.ZZ[int]

In 3.7+ however, the value of __orig_class__ is not available:

In [4]: import Simple
In [5]: a = Simple.ZZ[int]
In [6]: b = a()

AttributeError                            Traceback (most recent call last)
<ipython-input-6-52a6c422c17e> in <module>
----> 1 b = a()
/tool/pandora64/.package/python-3.7.0/lib/python3.7/typing.py in __call__(self, *args, **kwargs)
    668             raise TypeError(f"Type {self._name} cannot be instantiated; "
    669                             f"use {self._name.lower()}() instead")
--> 670         result = self.__origin__(*args, **kwargs)
    671         try:
    672             result.__orig_class__ = self
/proj/emu_scratch4/users/dbaltus/python/experiment/Simple.py in __init__(self)
      4 class ZZ(Generic[N]):
      5     def __init__(self):
----> 6         print("__orig_class__ is: ", self.__orig_class__)
AttributeError: 'ZZ' object has no attribute '__orig_class__'

> /proj/emu_scratch4/users/dbaltus/python/experiment/Simple.py(6)__init__()
      2
      3 N = TypeVar('N')
      4 class ZZ(Generic[N]):
      5     def __init__(self):
----> 6         print("__orig_class__ is: ", self.__orig_class__)
ipdb> q

This occurs because in 3.7, the __call__ method of _GenericAlias does not set the value of __orig_class__ until after __init__ is called. (It is done differently in 3.6).

    def __call__(self, *args, **kwargs):
        if not self._inst:
            raise TypeError(f"Type {self._name} cannot be instantiated; "
                            f"use {self._name.lower()}() instead")
        result = self.__origin__(*args, **kwargs)
        try:
            result.__orig_class__ = self
        except AttributeError:
            pass
        return result

srittau told us to open a new issue here, and locked the old conversation. I think it would be helpful to open a issue here for tracking and back-ref that old issue: python/typing#658

Workaround

Future people encountering this can use pytypes.get_orig_class as a workaround. Source code: https://github.com/Stewori/pytypes/blob/3846f1be3e44892c8e60f750f7581cbddd8be383/pytypes/type_util.py#L182

CPython versions tested on:

3.12

Operating systems tested on:

Linux, macOS

Linked PRs

• gh-123777: Allow __orig_class__ to be accessed in __init__ #123878

[XieJiSS]

And there's also a purposed solution in the old thread: python/typing#658 (comment)

This has been annoying me as of late, couldn't we just have it not be available in __new__ but available in __init__?

[picnixz]

First, 3.6 and 3.7 won't get any updates since they are EOL. 3.8 to 3.11 are security-only. As you observed, the object only has __orig_class__ available after it's has been initialized (still the same on 3.14) but I'm not sure we want to change that (sorry, I replied before reading the entire issue).

cc @JelleZijlstra

[ZeroIntensity]

Agreeing with @picnixz, the fix here might be problematic. I do have a fix ready (only for pure-Python types, to prevent breaking things in C), that calls __new__ first, then sets the __orig_class__, and then finally calls __init__. All the tests do indeed pass, but I'm worried that it could break something else that I'm not thinking about (and it's also an extra layer of complexity, nonetheless.)

FWIW, if you don't want to get around this with the pytypes library, you could access the self from the previous frame. For example:

import inspect
from typing import Generic, TypeVar

T = TypeVar("T")

class Test(Generic[T]):
    def __init__(self) -> None:
        frame = inspect.currentframe().f_back
        orig_class = frame.f_locals["self"]
        print(orig_class)  # Equivalent to __orig_class__

test = Test[int]()

At this point, I think this should be considered a feature. If I do submit my patch, it shouldn't be backported to 3.12 and 3.13. Years ago, in 3.7, this could probably have been considered a regression, but not at this point :(

[ZeroIntensity]

I've created #123878 to address this. @encukou, this is a feature at this point -- could you add type-feature and remove type-bug?

[AlexWaygood]

I've created #123878 to address this. @encukou, this is a feature at this point -- could you add type-feature and remove type-bug?

There's plenty of typing experts subscribed to this issue due to the topic-typing label having been added :-) no need to start tagging core devs who haven't commented here or expressed an interest on the issue elsewhere.

That said, I agree that even if we decide to change this (not saying we necessarily won't, just that I haven't had a chance to look at it properly yet!), it's pretty unlikely that we'll backport the change.

[ZeroIntensity]

no need to start tagging core devs who haven't commented here or expressed an interest on the issue elsewhere.

Petr specifically requested that I ping him for label changes 😄

[AlexWaygood]

Petr specifically requested that I ping him for label changes 😄

Oh, fair enough, sorry! I wasn't aware :-)

[XieJiSS]

As per the discussion happened in #123878, this should be closed as unplanned

For future people encountering the same issue: please use thirdparty solutions e.g. pytypes.get_orig_class to workaround this