[Python-Dev] Please reject or postpone PEP 526 (original) (raw)

Guido van Rossum guido at python.org
Mon Sep 5 11:34:20 EDT 2016

On Mon, Sep 5, 2016 at 7:19 AM, Mark Shannon <mark at hotpy.org> wrote:

On 04/09/16 21:16, Guido van Rossum wrote:

Everybody please stop panicking. PEP 526 does not make a stand on the behavior of type checkers (other than deferring to PEP 484). If you want to start a discussion about constraining type checkers please do it over at python-ideas. There is no rush as type checkers are not affected by the feature freeze. Indeed, we shouldn't panic. We should take our time, review this carefully and make sure that the version of typehints that lands in 3.7 is one that we most of us are happy with and all of us can at least tolerate.

Right, we want the best possible version to land in 3.7. And in order to make that possible, I have to accept it provisionally for 3.6 and Ivan's implementation will go into 3.6b1. We will then have until 3.7 to experiment with it and tweak it as necessary.

Maybe ClassVar will turn out to be pointless. Maybe we'll decide that we want to have a syntax for quickly annotating several variables with the same type (x, y, z: T). Maybe we'll change the rules for how or when annotations is updated. Maybe we'll change slightly whether we'll allow annotating complex assignment targets like x[f()].

But without starting the experiment now we won't be able to evaluate any of those things. Waiting until 3.7 is just going to cause the exact same discussions that are going on now 18 months from now.

Regarding how type checkers should use the new syntax, PEP 526 itself give barely more guidance than PEP 3107, except that we now have PEP 484 to tell us what types ought to look like, if you want to use an external type checker.

I hope that you and others will help write another PEP (informational?) to guide type checkers and their users. Given my own experience at Dropbox (much of it vicariously through the eyes of the many Dropbox engineers annotating their own code) I am very reluctant to try and specify the behavior of a type checker formally myself. As anyone who has used mypy on a sizeable project knows, there are a lot more details to sort out than how to handle branches that assign different values to the same variable.

For people who want to read about what it is like to use mypy seriously, I can recommend the series of three blog posts by Daniel Moisset starting here: http://www.machinalis.com/blog/a-day-with-mypy-part-1/

If you want to see a large open source code base that's annotated for mypy (with 97% coverage), I recommend looking at Zulip: https://github.com/zulip/zulip Try digging through the history and looking for commits mentioning mypy; a Google Summer of Code student did most of the work over the summer. (The syntax used is the Python-2-compatible version, but that's hardly relevant -- the important things to observe include how they use types and how they had to change their code to pacify mypy.)

-- --Guido van Rossum (python.org/~guido)

More information about the Python-Dev mailing list