Re: Typing syntax and ecosystem, take 2
From: Ned Batchelder <ned@nedbatchelder.com> [ munch ] This is very similar to statically typed languages. They also have two steps:
* There is the first step that checks the types but does not run the program. In C/C++, this is the compiler, in Python it is "mypy". * There is the second step that runs the program but does not check the types. In C/C++, this is running the executable, in Python it is "python".
In Python, we can skip the first step, and perhaps that is the source of your concern. I doubt anyone that has adopted type hinting in Python will forget to run mypy, especially in a CI environment like you consider.
In the current Python implementation, we can't skip the first step. Type hints have a significant performance impact on the Python interpreter, hence PEP 649. If we used the TypeScript approach, the typing hints would be removed before execution by the Python interpreter. As for "forget to run mypy", no-one sets out to do the wrong thing. The difference here is that with TypeScript -> JavaScript, if you forget to run the translation step, the program won't run because TypeScript is not valid JavaScript. Same was true for the old CFront C++ -> C translator. Errors are automatically detected. If you forget to run mypy, you've got a program which *looks* correct but might not be. -- cheers, Hugh Fisher
On 4/13/21 7:40 PM, Hugh Fisher wrote:
From: Ned Batchelder <ned@nedbatchelder.com> [ munch ] This is very similar to statically typed languages. They also have two steps:
* There is the first step that checks the types but does not run the program. In C/C++, this is the compiler, in Python it is "mypy". * There is the second step that runs the program but does not check the types. In C/C++, this is running the executable, in Python it is "python".
In Python, we can skip the first step, and perhaps that is the source of your concern. I doubt anyone that has adopted type hinting in Python will forget to run mypy, especially in a CI environment like you consider. In the current Python implementation, we can't skip the first step. Type hints have a significant performance impact on the Python interpreter, hence PEP 649. If we used the TypeScript approach, the typing hints would be removed before execution by the Python interpreter.
In another message, you alluded to PEP 649 being a solution to run-time type checking. Maybe I'm misunderstanding something: type annotations never do type checking at runtime. As I understand it, PEP 649 is about avoiding the overhead of evaluating the type expression itself, not about checking the types of values.
As for "forget to run mypy", no-one sets out to do the wrong thing. The difference here is that with TypeScript -> JavaScript, if you forget to run the translation step, the program won't run because TypeScript is not valid JavaScript. Same was true for the old CFront C++ -> C translator. Errors are automatically detected.
If you forget to run mypy, you've got a program which *looks* correct but might not be.
Yes, absolutely. But who is running mypy manually, and therefore could forget it? It will be a step in a Makefile, or a tox.ini, or a CI script. You are right that this approach to type checking can surprise people coming from other languages. And absolutely, you should not use type annotations without checking them. People will learn to do it right. --Ned.
On Wed, Apr 14, 2021 at 9:47 AM Hugh Fisher <hugo.fisher@gmail.com> wrote:
From: Ned Batchelder <ned@nedbatchelder.com> [ munch ] This is very similar to statically typed languages. They also have two steps:
* There is the first step that checks the types but does not run the program. In C/C++, this is the compiler, in Python it is "mypy". * There is the second step that runs the program but does not check the types. In C/C++, this is running the executable, in Python it is "python".
In Python, we can skip the first step, and perhaps that is the source of your concern. I doubt anyone that has adopted type hinting in Python will forget to run mypy, especially in a CI environment like you consider.
In the current Python implementation, we can't skip the first step. Type hints have a significant performance impact on the Python interpreter, hence PEP 649. If we used the TypeScript approach, the typing hints would be removed before execution by the Python interpreter.
You're advocating an approach that absolutely mandates running the type checker, but then caches the results in an executable file (the JS file built from the TS source). Python already has a caching system - the .pyc files - so if you're importing the same file more than once, the cost of parsing type annotations is pretty much equivalent to the cost of doing it in TypeScript. Let's not get caught up in unfair comparisons, and just focus on making Python as good as it possibly can be. ChrisA
participants (3)
-
Chris Angelico -
Hugh Fisher -
Ned Batchelder