On 4/13/21 7:40 PM, Hugh Fisher wrote:
From: Ned Batchelder <n...@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.

_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/WOKTMKWLZC7ZFM7D4TLRHBEG3AY7J527/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to