GeezerVison

I'm -1 on this fix. There is a bigger underlying issue. See #102615 (comment)

I have no idea what to do here, I defer to @Fidget-Spinner.

I'm now +1 on this approach after Nikita reminded me that ParamSpec intentionally has edge cases that we cant fix.

This PR should be reviewed after #102681
I think I might need to modify it afterwards :)

@AlexWaygood you can review this whenever you have the time.

@sobolevn, should we make the same changes we made here to _collections_abc._type_repr? The docstring of that function indicates it is meant to have identical functionality to typing._type_repr.

In fact... I wonder if we should just import _type_repr from _collections_abc in typing, instead of duplicating it between the two modules. It's obvious why _collections_abc shouldn't depend on typing, but I don't see any reason why typing shouldn't depend on _collections_abc. We already have import collections.abc at the top of the file.

@AlexWaygood I thought about making the similar change in _collections_abc._type_repr. But, what is the use-case?

Right now users can define their own classes with ParamSpec only using typing.Generic. So, no use for _collections_abc.
As far as I know, the only std type that supports it is _collections_abc.Callable, but it already supports the correct repr.

Any examples where this might be useful?

I also think that sharing implementation details (functions starting with _) creates high coupling and implicit contracts, which is bad thing.

Okay, those are all good points. I think it might be nice at least to update the docstring of typing._type_repr to remind us that there's a function with very similar functionality in _collections_abc, though. What do you think?

I will!