Repository navigation
Do not simplify Union at runtime? #536
Description
Currently unions are simplified at runtime, for example:
class B: ...
class C(B): ...
assert Union[C, B] is BAlso they are flattened, for example Union[A, Union[B, C]] evaluates to Union[A, B, C]. There are however some downsides:
- Simplification of unions is a concept related to static types, applying it at runtime might blur the distinction between static types and runtime classes.
- Implementation of this feature had bugs, all of them related to the fact that
issublcassis only applicable to proper classes, and it is not always easy to detect those beforehand. - This has some (although minor) runtime costs.
On the positive side:
- This still teaches people how unions work with subclasses
- It may be too late to change this.
Activity
gvanrossum commentedon Jan 29, 2018
reinhrst commentedon May 11, 2018
I would still like to have an option to retrieve the original (unsqashed) union parameters. This has to do with doing more advanced things than just type checking with the same hints (whether this is a good idea is perhaps a different discussion).
I'm currently trying to automatically validate json based on the python type hints at runtime. In this case:
should result in different validation rules than
to which the current
Unionevaluates.I see that it may be hard to fix this without losing backwards-compatibility. Pep-563 may give a way around this issue in most cases, however not if the union is not used directly in the type-hint:
gvanrossum commentedon May 11, 2018
That's an interesting point. I have softened a bit -- I think it would be reasonable if we didn't simplify unions (as long as the == relationship still works the same).
gvanrossum commentedon May 17, 2018
So looking at the PR, it only deletes the simplification of
Union[C, B]toB. It still flattens nested unions, still squashes singleton unions, and still removes redundant items. Hopefully that's enough for the typical use case (keepingUnion[int, bool]in a JSON schema).ilevkivskyi commentedon May 17, 2018
Yes, I think we can keep the other simplifications (to minimise possible incompatibility) while still fix the issue with schemas.
Also other simplifications never caused problems/complains, while
issubclass()call in subclass simplification caused several bugs in the past.gvanrossum commentedon May 17, 2018