Open KotlinIsland opened 2 years ago
I like this idea! It would reduce the need for PRs like https://github.com/python/cpython/pull/29355, which corrects an annoying inconsistency between the stub file and the runtime code, but is unlikely to get merged (no real use case, if we're honest).
Isn't the use case making the stubs more accurate mainly around type parameters?
That's the use case for making singledispatchmethod
generic in the stubs, of course. But I, for one, have no real use case for being able to parameterize singledispatchmethod
at runtime, other than wanting consistency with the stubs. Can you think of a situation when you'd want to use singledispatchmethod
in a type annotation, and therefore need to parameterize it?
As per the OP, my use case is mainly around dict_keys
and the rest of the collections
pre 1.9, also registered abc
s
I think we might be talking at cross purposes 🙂
As I said in my first message in this thread, I agree with your case — I like your idea! I was saying that there wasn't much of a use case for my previous PR to cpython that I linked to here, and that I liked your idea because it would reduce the need for PRs to cpython such as the one I linked to. My "no real use case, if we're honest" comment was referring to my PR to cpython, not your idea here 🙂
I think https://github.com/python/typeshed/issues/7436 would be a really nice use case for this.
The existing typing
decorators all use snake_case, so I think this new decorator should also use snake case (in accordance with PEP 8). I don't think stub-only should be in the name, because afaik everything currently in typing
can also be used in regular .py
files, so I think we should keep it that way.
There already is @typing.type_check_only
, so @typing.type_check_only_base_classes
would be analogous ... it is however a bit too verbose for my liking. I think simply @typing.base_classes
should be fine, what do you think?
I guess getting this into Python would require a PEP?
CC: @srittau, @JelleZijlstra
There are existing classes that extend things in an abstract way, like ABCs, and things that are
Generic
in theory but not in reality, for example all thecollections
(the collection classes are notGeneric
s, they define__class_getitem__
) and some are still not subscribe-able but state they are in the stubs, for instance_collections_abc.dict_keys
or any of the collections pre 3.9.It could be used something like:
Mapping
doesn't actually extendGeneric
, butContainer
defines__class_getitem__
, so that would also need to be updated in the stubs.This might help resolve https://github.com/python/mypy/issues/3186, but still indicate that it's not actually one of the bases.
I think a change like this would make the stubs much more understandable and closer to the actual implementation, also fixing issues about older python versions not working properly with the current stubs(https://github.com/python/mypy/issues/11529).
I personally find it very confusing when referencing the stubs that the bases are often false.
No idea how this would be used in a real life annotation, but a workaround that works is:
https://github.com/python/typeshed/pull/6312#issuecomment-976036379 https://github.com/python/typeshed/issues/6257
Obligatory shill to #953, which I think would render this moot.