This PR does mean that partial evaluations of the different ways of writing unions aren't quite equivalent. A union written with| with an element that can't be evaluated gives no information about the types, while a union written withUnion[...] gives partial information¹.

• str | undefined ->ForwardRef('__annotationlib_name__1 | undefined', ...)
• Union[str, undefined] ->str | ForwardRef('undefined', ...)

This does make me think that perhaps the previous change to makea | b intoUnion[a, b]might still be worth doing? Arguablya andb in this case are forward references and| between forward references creates a union.

If not, then perhaps the__extra_names__ should be more visible to help distinguish between otherwise similar looking forward references with different contents.

Example:

fromannotationlibimportget_annotations,FormatclassEx1:a:str|undefinedb:str|int|undefinedfork,vinget_annotations(Ex1,format=Format.FORWARDREF).items():print(f"{k}:{v}")

a: ForwardRef('__annotationlib_name_1__ | undefined', is_class=True, owner=<class '__main__.Ex1'>)b: ForwardRef('__annotationlib_name_2__ | undefined', is_class=True, owner=<class '__main__.Ex1'>)

I sort of think that's correct: if we don't know what A and B are, we don't know whatA | B will evaluate to. It might be a union, but it might be something else too if A happens to implement__or__ some other way.

We could perhaps hide the__annotation_name_1__ names in the repr() of ForwardRefs, though, do you think that would be better?

I sort of think that's correct: if we don't know what A and B are, we don't know whatA | B will evaluate to. It might be a union, but it might be something else too if A happens to implement__or__ some other way.

My logic is more along the lines of - if a name can't be resolved it becomes a forward ref, anything that uses| with a forwardref becomes a union¹ thus it makes sense by that logic for this to become a union.

The other reasoning is that a runtime checker could use the partial information to know that an argument is valid in the case where you get a union, if the type is one of the elements that does resolve, but couldn't do so in the case where the entire statement is a forwardref. I'm not sure how common this case would be though.

We could perhaps hide the__annotation_name_1__ names in the repr() of ForwardRefs, though, do you think that would be better?

I'm not sure about this one, I know therepr already isn't exactly complete though with all the hidden internals.

It still feels wrong to me to special-case just__or__; your suggestion would mean this operator works differently than all the others.

I'm actually not convincedForwardRef.__or__ should exist at all, as ForwardRefs shouldn't be created in a place where users create Unions out of them. It was added inhttps://bugs.python.org/issue45489 without much discussion. Removing it would be a compatibility issue at this point though, so I'm not proposing it.

That makes sense, it just bugs me that this meansa | b is not the same asUnion[a, b] if you're using type hints in this context (and one happens to be a forwardref). Unfortunately tools likepyupgrade will automatically convertUnion syntax to| and now in this case they're not equivalent.

⚠️⚠️⚠️ Buildbot failure⚠️⚠️⚠️

Hi! The buildbotiOS ARM64 Simulator 3.x (tier-3) has failed when building commitc8f233c.

What do you need to do:

1. Don't panic.
2. Checkthe buildbot page in the devguide if you don't know what the buildbots are or how they work.
3. Go to the page of the buildbot that failed (https://buildbot.python.org/#/builders/1380/builds/3537) and take a look at the build logs.
4. Check if the failure is related to this commit (c8f233c) or if it is a false positive.
5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/#/builders/1380/builds/3537

Summary of the results of the build (if available):

==

Traceback (most recent call last):  File"/Users/buildbot/Library/Developer/XCTestDevices/99D824FA-F7CC-45B8-8E9C-C9B3DCBBA39B/data/Containers/Bundle/Application/9DCD2A29-C3D4-4FA7-B324-25A9D853418C/iOSTestbed.app/python/lib/python3.14/threading.py", line1079, in_bootstrap_innerself._context.run(self.run)~~~~~~~~~~~~~~~~~^^^^^^^^^^  File"/Users/buildbot/Library/Developer/XCTestDevices/99D824FA-F7CC-45B8-8E9C-C9B3DCBBA39B/data/Containers/Bundle/Application/9DCD2A29-C3D4-4FA7-B324-25A9D853418C/iOSTestbed.app/python/lib/python3.14/threading.py", line1021, inrunself._target(*self._args,**self._kwargs)~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  File"/Users/buildbot/Library/Developer/XCTestDevices/99D824FA-F7CC-45B8-8E9C-C9B3DCBBA39B/data/Containers/Bundle/Application/9DCD2A29-C3D4-4FA7-B324-25A9D853418C/iOSTestbed.app/python/lib/python3.14/test/test_interpreters/test_stress.py", line30, intask    interp= interpreters.create()  File"/Users/buildbot/Library/Developer/XCTestDevices/99D824FA-F7CC-45B8-8E9C-C9B3DCBBA39B/data/Containers/Bundle/Application/9DCD2A29-C3D4-4FA7-B324-25A9D853418C/iOSTestbed.app/python/lib/python3.14/test/support/interpreters/__init__.py", line76, increateid= _interpreters.create(reqrefs=True)interpreters.InterpreterError:interpreter creation failedk