Message 412083 - Python tracker

➜

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	gvanrossum
Recipients	AlexWaygood, JelleZijlstra, gvanrossum, kj, sobolevn
Date	2022-01-29.16:53:37
SpamBayes Score	-1.0
Marked as misclassified	Yes
Message-id	<1643475217.25.0.83576890903.issue46571@roundup.psfhosted.org>
In-reply-to

Content
@no_type_check (introduced by PEP 484) is intended for static checkers, to signal to them that they shouldn't check the given function or class. I don't think PEP 484 specifies its runtime effect -- arguably get_type_hints() could just ignore it. Or raise an exception when called on such a class. We could even argue that @no_type_check shouldn't have a runtime effect. But before we change anything we should be guided by: 1. What is documented? 2. What does it do now? 3. How is that used by runtime type inspectors? 4. What would be most useful to runtime type inspectors?

@no_type_check (introduced by PEP 484) is intended for static checkers, to signal to them that they shouldn't check the given function or class.

I don't think PEP 484 specifies its runtime effect -- arguably get_type_hints() could just ignore it. Or raise an exception when called on such a class. We could even argue that @no_type_check shouldn't have a runtime effect.

But before we change anything we should be guided by:

1. What is documented?
2. What does it do now?
3. How is that used by runtime type inspectors?
4. What would be most useful to runtime type inspectors?

History
Date	User	Action	Args
2022-01-29 16:53:37	gvanrossum	set	recipients: + gvanrossum, JelleZijlstra, sobolevn, kj, AlexWaygood
2022-01-29 16:53:37	gvanrossum	set	messageid: <1643475217.25.0.83576890903.issue46571@roundup.psfhosted.org>
2022-01-29 16:53:37	gvanrossum	link	issue46571 messages
2022-01-29 16:53:37	gvanrossum	create