I happen to give a talk just yesterday that was about pretty much this ( https://github.com/DavidMertz/PythonRuntimeTyping; hopefully PyCon MEA publishes video after a bit).

I illustrate checking the same program using mypy, pytype, and pyright. There is a lot of overlap in what they flag as problems, but indeed there are significant differences. However, the differences are because of different GOALS in the programs.

For example, mypy very explicitly only pays attention to code that is explicitly annotated. Pytype performs actual type inference as well, and sometimes identifies problems even in completely non-annotated code; at the same time, pytype deliberately ignores things that are "wrong" but that will not affect runtime behavior. Pyright is the most "aggressive" of these tools (I haven't really played with pyre) but that is exactly appropriate because the tool is mostly used as a plugin to VS Code (maybe other editors), where the cost of a false positive complaint is small, and the cost of a false negative is more important.

All three of these tools serve a reasonable, but different purpose. Of course they overlap to a large degree, but it would be bad to declare that only one of these purposes was "legitimate."

On Fri, Oct 14, 2022 at 4:38 AM Christopher Barker pythonchb@gmail.com wrote:

Static type analysis is still experimental in Python.

Evidence for this is that there ARE multiple type checkers, and they don’t all behave the same way.

It really needs to settle down before there is a single “official” type checker.

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.

-CHB

On Thu, Oct 13, 2022 at 9:23 AM pvmpatch@163.com wrote:

...

I’m doing some research on Python type annotations recently. I found that, some dynamic typing related bugs can be effectively avoided in the early stages of code development, by adding type annotations to Python code and applying some type checking tools (such as MyPy, PyType, Pyright, and Pyre, etc.). The introduction of type annotations effectively improves the type safety of Python code.

However, different tools discover, classify and report defects in different ways, and there is little overlap in the defects they reported. In the same code segment, some type checking tools will report defects but some will not. These may confuse users. Because it is not easy for the user to determine which tools give credible results.

Based on the above, I have the following suggestion: Is it possible that Python provide a new type checker officially? Or is it possible that Python choose one of the off-the-shelf type checking tools as the official and recommended one?

Python is my favourite programming language. I sincerely hope that I can help Python become stronger and safer. I hope this idea can be useful for you. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/CG2IGZ... Code of Conduct: http://python.org/psf/codeofconduct/

-- Christopher Barker, PhD (Chris)

Python Language Consulting

• Teaching
• Scientific Software Development
• Desktop GUI and Web Development
• wxPython, numpy, scipy, Cython

---

Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/UFEWUO... Code of Conduct: http://python.org/psf/codeofconduct/

On Fri, 14 Oct 2022 at 01:41, Christopher Barker pythonchb@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

On Fri, 14 Oct 2022 at 19:36, Christopher Barker pythonchb@gmail.com wrote:

I’m sorry that my typing-skepticism came across too strong, but while the tone and language revealed my personal view, I still think the points were correct.

Paul: I didn’t say annotations were experimental. I said “static typing” is — and I really think it still is, though “immature” is a better word.

I don't know that I'd agree with you, but it's not that important, as static typing isn't (and will never be) something provided by (core) Python.

Better evidence than the multiple implementations is the still unsettled state of PEP 563 and the number of typing-related PEPs introduced in the last few Python releases.

Fair. There *is* a lot of change. But "experimental" for me has a more negative implication than simply a rapid pace of change. As I say, it's not that important though.

My point stands: Static type analysis tools are not stable enough at this point to choose an “official” one.

My point is that we shouldn't *ever* expect to choose an official tool. Diversity is good and there's multiple (not entirely compatible) use cases. It's not the job of the stdlib (or "Python") to pick one library over another. Libraries get to be in the stdlib because the *community* chooses them. And in this case, probably not even then (see below).

I guess we may be agreeing here. But I wasn't certain from your comments who you were expecting to do the "choosing" - it felt like you expected the stdlib/core devs to make the call, but if I got that wrong, then fair enough.

But Paul’s point is better- This kind of development tool doesn’t belong in the stdlib at all — the features that are needed to support static type checkers do, which is why they have been added (and still are), but not the tool(s) itself.

And I’m confused about your point about my directing my typing rants at the Core devs— this is Python ideas, not Python-dev, and a community member suggested that Static Type analysis be standardized— how was my response not directed at the community ?

Your comments that static typing is experimental felt like they were directed at the core devs, and your overall skepticism about typing (some of which I share, to be clear) feels very much like you want *less* type annotation support in the stdlib/core, not that you think what's there is about right and community members need to understand that "in the core" doesn't equate to "mandatory". On the contrary, you give the impression that you *already* feel that typing is being forced on people who don't want it - by the language and the core devs, not by the community.

If you'd addressed the suggestion that static type analysis be standardised by saying "Python has a clear policy that type annotations are optional, and checking will never be enforced by the language, so standardising a specific type checker isn't really appropriate" then that would have felt much more clearly directed at the community.

But whatever, you're entitled to your opinions, and you're entitled to express them how you wish, so I don't want to dissect your wording and read things into it that you didn't intend. Sorry if I did so.

And your example of PEP 8 is an excellent one: PEP 8 is a style guide for the standard library itself. But that gives it a perceived endorsement as an all-Python standard — I’m suggesting that we wouldn’t want to accidentally provide a similar perceived endorsement of a particular static type checker.

I'd go further and say that we (by which I mean "the Python community") should work hard to oppose any drift towards the sort of corrosive insistence that everyone "must" follow rules, or use tools, that are intended as guidelines and helpers, which surrounds the whole "PEP 8 compliance" idea. And in particular, we should push back hard on a similar mindset taking hold regarding type annotations.

Paul