On Fri, 14 Oct 2022 at 01:41, Christopher Barker <python...@gmail.com> wrote:
> Static type analysis is still experimental in Python. > It's not. This is simply false. Type *annotations* are a standard part of the language, supported by language syntax, a standard library module, and a series of PEPs describing various features. None of this is any more experimental than, say, context managers. Type *analysis* is not a feature of Python. It's something that's implemented in a number of third party tools, which address different (but all equally legitimate) use cases. It is a deliberate, and repeatedly confirmed, design decision that the core Python language does *not* enforce behaviour based on type annotations. Evidence for this is that there ARE multiple type checkers, and they don’t > all behave the same way. > This is *not* evidence that typing is experimental. It is evidence that a language feature (type annotations) can be used in different ways, depending on the use case. It is, however, evidence that there are multiple use cases here, served by different 3rd party projects, and that suggests that type checking is *not* suitable for inclusion in the standard library. The standard library is a good place for stable code that will change rarely if ever, and which addresses a wide range of use cases. None of which applies to the existing type checking applications. (Also, the standard library is intended for *libraries*, not *applications*...) > It really needs to settle down before there is a single “official” type > checker. > It's not clear that there will *ever* be a situation where only one type checker satisfies everyone. Any more than there's ever likely to be a single web framework. > Also: Static type checking is optional in Python. There are those of us > that are not convinced that static type checking is or should be a Python > best practice. An official type checker would be an endorsement not just of > that particular approach to type checking, but also the concept itself — I > don’t think the community is ready for that. > At this point, I think that repeating this assertion is simply FUD. Yes, using type annotations and a type checker is optional. So is using context managers or decorators. But we don't keep insisting that "not everyone likes decorators, the community isn't ready for them". It *is* true that there is an element in the community that pushes the idea that everything should be type checked. But that's not new. There are people who insist that PEP 8 is mandatory and linters that report PEP 8 violations should be applied to all code. IDEs like VS Code have plugins that run PEP 8 checks on your code and whine at you if you don't "fix" violations. Type checking is in a very similar position. But the response to this is to point out to such zealots that they are *wrong* and that type annotations (and PEP 8) are *tools* to help users, not rules to constrain them. If you want to remind people that not all code needs to be type checked, and that writing a script (or even a big project) with no annotations is perfectly acceptable, then please, do so - I'd completely support that. But at this point, please *stop* directing such reminders at core Python - it's long past the point where it's clear that no-one on the core team is trying to force type checking on users, and it's the *community* that needs educating in this, not the core team. Paul
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/4HTLMV4UAFSCC3F4FDTBICE4VUVYDM3E/ Code of Conduct: http://python.org/psf/codeofconduct/
