I think that we should document this in one place, no need to duplicate this info.

Do you mean the existing duplication betweentyping.rst andtyping.py? I assume it's intended so I don't want to make the two diverge by only updating one of them.

Or is it that you'd prefer a separate section for mentioning thatUnion/Literal/Annotated flattening doesn't work withTypeAliasType, instead of it being inlined within each type's respective documentation?

I'd rather document a specific caveat about a feature as close as possible to where the feature itself is documented, otherwise it could easily be missed by readers. And since the flattening behavior is explained in each type's respective documentation, it makes sense to follow suit. I'm guessing that this is the intent of the original authors as the overall redundancy in the properties listed forUnion/Literal/Annotated probably reduces the need to jump up and down the page to a hypothetical common section about "union-like" types when reading.

In general, the docstrings are meant to be more concise. I think the new information in this PR is specialized enough that we can document it only in typing.rst and not the docstrings.

Alright I'll only modifytyping.rst

This sentence is likely to cause confusion for many readers. Literal and Union are very different things in the type system.

Would it be better as "The Literal annotation supports the same operations as Union"?

I think it's better not to draw comparisons. Literal and Union have similar runtime behavior but they mean different things, and I don't think it will help most readers to compare them.

Fair enough

In general, the docstrings are meant to be more concise. I think the new information in this PR is specialized enough that we can document it only in typing.rst and not the docstrings.