-
Notifications
You must be signed in to change notification settings - Fork 249
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
typing/Generic __orig_class__ availability during __init__ in 3.6 vs 3.7 #658
Comments
Yes, this is unfortunate, but as you know, this is undocumented internal attribute that you are using totally at your own risk. So unless you have a simple idea how to fix this, I don't think there is anything we can do here. |
… more. Exposed workaround for python/typing#658 as new public API get_orig_class. Added doc to quick manual for this new function.
@baltus-atomicrules |
Sure, but that makes also typing_inspect fail inside constructor: ilevkivskyi/typing_inspect#35 |
We can't change what typing looks like in 3.6 or 3.7, so I don't think there's anything actionable in this issue. |
I mean, the same still holds true in 3.8, 3.9, 3.10. So the issue in all of those that inside |
We just fallback to `typing.Any` and make an explicit type-cast, instead of resolving the generic type argument at runtime to automatically get the reference to `uuid_subtype_func`. Here is the story: Currently Python does not allow introspection of generic type arguments in runtime. For some limited cases, we could refer `__orig_bases__`, but somehow it does not work for us and it is a known limitation that we cann t resolve it early in the object lifecycle. (ref: https://stackoverflow.com/questions/57706180, python/typing#658) Moreover, SQLAlchemy's `TypeDecorator` also involves its own metaclass logic from `TraversibleType`, which makes `__orig_class__` unavailable.
* setup: Set the minimum mypy version to 0.930 * fix: New typecheck errors due to stricter enum validation * fix: Workaround limitation of type variable usage in ClassVar We just fallback to `typing.Any` and make an explicit type-cast, instead of resolving the generic type argument at runtime to automatically get the reference to `uuid_subtype_func`. Here is the story: Currently Python does not allow introspection of generic type arguments in runtime. For some limited cases, we could refer `__orig_bases__`, but somehow it does not work for us and it is a known limitation that we cann t resolve it early in the object lifecycle. (ref: https://stackoverflow.com/questions/57706180, python/typing#658) Moreover, SQLAlchemy's `TypeDecorator` also involves its own metaclass logic from `TraversibleType`, which makes `__orig_class__` unavailable.
* setup: Set the minimum mypy version to 0.930 * fix: New typecheck errors due to stricter enum validation * fix: Workaround limitation of type variable usage in ClassVar We just fallback to `typing.Any` and make an explicit type-cast, instead of resolving the generic type argument at runtime to automatically get the reference to `uuid_subtype_func`. Here is the story: Currently Python does not allow introspection of generic type arguments in runtime. For some limited cases, we could refer `__orig_bases__`, but somehow it does not work for us and it is a known limitation that we cann t resolve it early in the object lifecycle. (ref: https://stackoverflow.com/questions/57706180, python/typing#658) Moreover, SQLAlchemy's `TypeDecorator` also involves its own metaclass logic from `TraversibleType`, which makes `__orig_class__` unavailable. Backported-From: main (22.03) Backported-To: 21.09
* setup: Set the minimum mypy version to 0.930 * fix: New typecheck errors due to stricter enum validation * fix: Workaround limitation of type variable usage in ClassVar We just fallback to `typing.Any` and make an explicit type-cast, instead of resolving the generic type argument at runtime to automatically get the reference to `uuid_subtype_func`. Here is the story: Currently Python does not allow introspection of generic type arguments in runtime. For some limited cases, we could refer `__orig_bases__`, but somehow it does not work for us and it is a known limitation that we cann t resolve it early in the object lifecycle. (ref: https://stackoverflow.com/questions/57706180, python/typing#658) Moreover, SQLAlchemy's `TypeDecorator` also involves its own metaclass logic from `TraversibleType`, which makes `__orig_class__` unavailable. Backported-From: main (22.03) Backported-To: 21.03
This has been annoying me as of late, couldn't we just have it not be available in |
Hi, is there any updates? Thanks |
I still face this issue with Python 3.11. Are there any valid workarounds for this? |
Please report any issues related to issues with the |
I 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
(I am comparing 3.6.7 with 3.7.0)
I've attached a simple example that defines a Generic class and then accesses __orig_class__ in the associated __init__ method.
Simple.py.txt
In 3.6, this code runs fine:
In 3.7 however, the value of __orig_class__ is not available:
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).
The text was updated successfully, but these errors were encountered: