This can wait for v3, as if the field has a default it is currently treated as a class var anyway. This todo is thus linked in#11119.

Might need a new code

Might as well 🤷

Why isis_generic_alias not included intyping_inspection?

is_generic_alias does anisinstance() check againsttyping._GenericAlias (e.g.List[int] is an instance of such a class), which isn't documented and technically private (although I don't think it will change). So it's best to avoid relying on it.

It is also a footgun as whileis_generic_alias() works for all parameterized typing objects, it doesn't check for new unions (is_generic_alias(int | str) == False, butis_generic_alias(Union[int, str]) == True). For instance, I'm not sure we expected new unions to be skipped here:

Similarly, I've used this function here as a way to check fortype[list[int]] forms (heretype_param islist[int]):

This would also matchtype[Union[int, str]], which we actually want to support! Thankfully there's a specific check for unions just before, but this could easily be missed.

I think there are still valid use cases where you want to check if something is a generic alias (and by that I don't meanisinstance(obj, (types.GenericAlias, typing._GenericAlias), but if theobj is a parameterized generic class -- excluding unions, typing special forms likeLiteral,Annotated, etc), but it's probably best to rely onget_origin() and thetyping_objects check functions.

I presume it's expected that the origin is always fetched before feeding into a typing objects check?

Yes, as per the guide, for performance reasons and also to have a cleaner approach, you should callget_origin() once, and the use thetyping_objects.is_smth(origin) functions to analyze the object.

In Pydantic, ouris_smth() functions were already callingget_origin(), but then we can end up with patterns like:

ifis_annotated(obj):# one get_origin() call under the hood    ...elifis_literal(obj):# two get_origin() calls now    ...

This was convenient as shown on thisif _typing_extra.is_annotated() call, but can decrease performance overall.

Yes, definitely good to minimizeget_origin calls.

Wouldis_type_alias_type make more sense?

I wanted to avoid having the name depending on the capitalization of the object, and simply haveis_<name>, but both make sense I think

I'd preferis_type_alias_type just bc it's easier to read, but it's up to you, doesn't really matter!

Why not justis_union?

To not confuse it withtyping_object.is_union(), which only checks fortyping.Union (as it does for all the other functions intyping_objects), I've tried finding a better name but couldn't find any

Discussed at standup today, could be changed for clarity on thetyping-inspection end, but I don't think this PR needs to be held up because of it.

Why are we yielding fromget_literal_values? Seems like we always wrap in alist?

We (Pydantic) always wrap in a list, but others might not:

foreleminget_literal_values(Literal[1,2]):    ...

Doesn't strike me as necessary, but also, very low stakes, feel free to leave it as you wish