[Python-ideas] Proposal to extend PEP 484 (gradual typing) to support Python 2.7

[Guido van Rossum]

On Mon, Jan 11, 2016 at 10:10 AM, Matthias Kramm <kramm at google.com> wrote:

> On Friday, January 8, 2016 at 3:06:05 PM UTC-8, Guido van Rossum wrote:
>>
>> At Dropbox we're trying to be good citizens and we're working towards
>> introducing gradual typing (PEP 484) into our Python code bases (several
>> million lines of code). However, that code base is mostly still Python 2.7
>> and we believe that we should introduce gradual typing first and start
>> working on conversion to Python 3 second (since having static types in the
>> code can help a big refactoring like that).
>>
>> Since Python 2 doesn't support function annotations we've had to look for
>> alternatives. We considered stub files, a magic codec, docstrings, and
>> additional `# type:` comments. In the end we decided that `# type:`
>> comments are the most robust approach.
>>
>
> FWIW, we had the same problem at Google. (Almost) all our code is Python
> 2. However, we went the route of backporting the type annotations grammar
> from Python 3. We now run a custom Python 2 that knows about PEP 3107.
>

Yeah, we looked into this but we use many 3rd party tools that would not
know what to do with the new syntax, so that's why we went the route of
adding support for these comments to mypy.


> The primary reasons are aesthetic - PEP 484 syntax is already a bit hard
> on the eyes (capitalized container names, square brackets, quoting, ...) ,
> and squeezing it all into comments wouldn't have helped matters, and would
> have hindered adoption.
>

Possibly. I haven't had any pushback about this from the Dropbox engineers
who have seen this so far.


> We're still happy with our decision of running a custom Python 2, but your
> mileage might vary. It's certainly true that other tools (pylint etc.) need
> to learn to not be confused by the "odd" Python 2 syntax.
>

We had some relevant experience with pyxl, and basically it wasn't good --
too many tools had to had custom support added or simply can't be used on
files containing pyxl syntax. (https://github.com/dropbox/pyxl)


> [1] I have a prototype of such a tool, i mplemented as a 2to3 fixer. It's
>> a bit over 200 lines. It's not very interesting yet, since it sets the
>> types of nearly all arguments to 'Any'. We're considering building a much
>> more advanced version that tries to guess much better argument types using
>> some form of whole-program analysis. I've heard that Facebook's Hack
>> project got a lot of mileage out of such a tool. I don't yet know how to
>> write it yet -- possibly we could use a variant of mypy's type inference
>> engine, or alternatively we might be able to use something like Jedi (
>> https://github.com/davidhalter/jedi).
>>
>
> pytype (http://github.com/google/pytype) already does (context sensitive,
> path-sensitive) whole-program analysis, and we're working on making it
> (more) PEP 484 compatible. We're also writing a (2to3 based) tool for
> inserting the derived tools back into the source code. Should we join
> forces?
>

I would love to! Perhaps we can take this discussion off line?

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160111/e1c0d0c9/attachment.html>