[Python-ideas] Typecheckers: there can be only one

[Steven D'Aprano]

On Wed, Sep 07, 2016 at 07:28:30PM +1000, Hugh Fisher wrote:
> There's been discussion here and on python-dev regarding PEP 526 that
> assumes there will be multiple type checkers for Python. I really
> can't see this happening.

As Ryan has already pointed out, that has already happened.


> If typing annotations become common or maybe
> considered best practice, the Zen of Python "there should be one-- and
> preferably only one --obvious way to do it" will take effect.

Like there is only one linter?

PyFlakes, PyChecker, Jedi, PyLint... which is the One Obvious Way?

But it doesn't really matter if the Python ecosystem eventually 
converges on one single linter or one single type checker. That's just a 
matter of market share. If there's one linter that is just so good that 
it completely dominates the community, well, that's fine. What matters 
the language allows the existence of multiple checkers competing on 
quality and features.


> Firstly, the interpreter will need to have type checking built in.

"Need" is very strong. I dare say that *eventually* some Python 
interpreters will have *some* soft of type checking built-in. Possibly 
even CPython itself.

But it will always be an optional, off-by-default, feature, because if 
it is mandatory, the language you are using won't be Python, it will be 
some more-or-less close subset of Python. (Like StrongTalk compared to 
SmallTalk, or TrueScript compared to Javascript.)

Fundamentally, Python will always be a dynamically-typed language, not a 
statically-typed one. Guido has been clear about that ever since he 
first proposed the idea of optional static typing more than a decade 
ago. Nothing has changed.

http://www.artima.com/weblogs/viewpost.jsp?thread=85551


> Just about every intro book and tutorial for Python says how great it
> is that you don't have an edit-save-compile cycle, just fire up the
> Python interpreter and start typing.

Right. And that won't change.


> Having to run a separate type
> checker will be considered as ridiculous as a C compiler that didn't
> run the preprocessor itself.
> 
> Secondly, PyPI will collapse if there isn't just one. How can we
> express dependencies between packages that use different type
> checkers? When type checkers themselves have versions? When a dev team
> uses one type checker for 1.x and then switches to another for 2.x?
> That's a special circle of hell.

I fear that you haven't grasped the fundamental difference between 
gradual static typing of a dynamically-typed language like Python, and 
non-gradual typing of statically-typed languages like C, Haskell, Java, 
etc. Your statement seems like a reasonable fear if you think of static 
typing as a mandatory pre-compilation step which prevents the code from 
compiling or running if it doesn't pass. But it makes no sense in the 
context of an optional code analysis step which warns of things which 
may lead to runtime exceptions.

I think that a good analogy here is that type checkers in the Python 
ecosystem are equivalent to static analysis tools like Coverity and 
BLAST in the C ecosystem.

In the C ecosystem, it doesn't make sense to ask how you can express 
dependencies between packages that have been checked by Coverity versus 
those that have been checked by BLAST. The very question is irrelevant, 
and there's no reason not to check your package by *both*. Or neither. 
Or something else instead.


-- 
Steve