This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author AlexWaygood
Recipients AlexWaygood, gvanrossum, kj, lukasz.langa, rhettinger, serhiy.storchaka
Date 2021-12-29.18:15:43
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1640801743.77.0.626009972873.issue46191@roundup.psfhosted.org>
In-reply-to
Content
I like Serhiy's idea from a type-checking perspective. It would mean we could continue to have sophisticated type inference from mypy/pyright/etc. inside singledispatch function definitions. It would also mean people could use type annotations in singledispatch functions in much the same way as in the rest of their code, instead of having to remember that *this specific stdlib function* works differently. Lastly, it avoids having to have each type-checker separately special-case singledispatch so that they do not raise an error when an unparameterised generic is used as a type annotation. 

My concern, however, is that the runtime semantics are slightly unintuitive. Registering an implementation to the "type" `list[str]` (and having it succeed without an error being raised) might give the false implication that there will be runtime checking of whether all the elements in a list are strings.

I also think that GenericAlias objects should probably only be accepted in the form of `singledispatch.register()` that parses type annotations. There's no use case for allowing GenericAlias objects in the other forms of registering implementations.
History
Date User Action Args
2021-12-29 18:15:43AlexWaygoodsetrecipients: + AlexWaygood, gvanrossum, rhettinger, lukasz.langa, serhiy.storchaka, kj
2021-12-29 18:15:43AlexWaygoodsetmessageid: <1640801743.77.0.626009972873.issue46191@roundup.psfhosted.org>
2021-12-29 18:15:43AlexWaygoodlinkissue46191 messages
2021-12-29 18:15:43AlexWaygoodcreate