Repository navigation
Python 3.11.9 catches all exceptions raised in Generic.__setattr__("__orig_class__", type_parameter) #117744
Description
Activity
__orig_class__itself is semi-documented state. It's documented in PEP but as internal typing implementation detail. A public api to retrieve them did get added here, but I think setting/modifying them remains internal behavior/undocumented on whether it should work.Also from motivation of that PR I don't see a reasonable way to revert that pr without breaking original issue it was intended for. So I'd discourage relying on modifying
__orig_class__or if you do accepting that it's unstable and may change rules.edit: I misremembered PEP 560.
__orig_bases__is mentioned in PEP with typing internal motivation.__orig_class__I'm unsure if it is mentioned at all in any public documentation/pep.Reacted by Jelle ZijlstraThank you for your reply!
orig_class itself is semi-documented state. It's documented in PEP but as internal typing implementation detail. A public api to retrieve them did get added #101688, but I think setting/modifying them remains internal behavior/undocumented on whether it should work.
RIght, I appreciate that
__orig_class__is an internal typing implementation detail and hence I cannot trust its interface to remain stable. That said...Also from motivation of that PR I don't see a reasonable way to revert that pr without breaking original issue it was intended for.
Catching all
Exceptionsseems a bit extreme to me. Why not catchTypeErrorandAttributeErrorspecifically? That would solve the original issue, right?Tweaking the set of exceptions caught is bound to cause more bugs in the future, if someone has a buggy
__setattr__that raises an unexpected exception.My inclination is to close this as "won't fix", and decide that your use case is unsupported.
Reacted by Alex WaygoodReacted by Cristian PietrobonWhy not catch
TypeErrorandAttributeErrorspecifically?Honestly, I think the only reasonable exception for people to raise in
__setattr__methods, property setters and similar isAttributeError. Which would imply that we should only catchAttributeErrorwhen setting__orig_class__(the behaviour we had prior to #115213). But in the "real world", there's lots of "unreasonable" code out there -- it's sadly pretty common for people to raise all sorts of exceptions from__setattr__methods.Note that although #115165 was only reported regarding
typing.Annotated, the actual bug there affected all generic aliases, such that code like this would raiseRuntimeError:class Foo[T]: def __setattr__(self, attr): raise RuntimeError("NO!") Foo[int]()
That feels like really surprising behaviour to me; I think it would be unacceptable to go back to that.
I agree with @JelleZijlstra here; I think we have to close this as "won't fix".
Alright, got it! Think I might have found a way to resolve this without relying on
__orig_class__too, which is probably for the best.Thanks for you time and feedback!
Reacted by Alex WaygoodNo problem -- thanks for the well-written bug report @nanne-aben!
Reacted by nanne-aben
Bug report
Bug description:
In Python 3.11.9, the following code does not raise an
Exception:In other versions of Python (e.g. 3.11.8 or 3.12.2) this raises an
Exception, but in Python 3.11.9 it appears thisExceptionis caught.I use something similar to the above logic in typedspark to check whether the
DataSetfollows the schema specified inSchema, and I raise anExceptionif it doesn't. As of Python 3.11.9, these exceptions are caught, hence breaking my logic.Thank you for looking into this!
CPython versions tested on:
3.9, 3.10, 3.11, 3.12
Operating systems tested on:
Linux, macOS, Windows