[Python-ideas] Proposal: Use mypy syntax for function annotations

[Andrew Barnert]

On Aug 20, 2014, at 7:25, Donald Stufft <donald at stufft.io> wrote:

> 
>> On Aug 20, 2014, at 10:11 AM, Brett Cannon <brett at python.org> wrote:
>> 
>> 
>> 
>> On Wed Aug 20 2014 at 9:29:34 AM Paul Moore <p.f.moore at gmail.com> wrote:
>>> On 14 August 2014 00:30, Guido van Rossum <guido at python.org> wrote:
>>> > We certainly *could* do that. However, I haven't seen sufficient other uses
>>> > of annotations. If there is only one use for annotations (going forward),
>>> > annotations would be unambiguous. If we allow different types of
>>> > annotations, there would have to be a way to tell whether a particular
>>> > annotation is intended as a type annotation or not. Currently mypy ignores
>>> > all modules that don't import typing.py (using any form of import
>>> > statement), and we could continue this convention. But it would mean that
>>> > something like this would still require the typing import in order to be
>>> > checked by mypy:
>>> >
>>> > import typing
>>> >
>>> > def gcd(int a, int b) -> int:
>>> >     <tralala>
>>> 
>>> Sorry, I'm slowly going through this thread, so my apologies if this
>>> has been covered later, but it seems to me that projects (and in
>>> particular libraries) that want to target 2.7 as well as 3.x will be
>>> forced to avoid this feature. And avoid any dependencies that use it.
>>> 
>>> Specifically, the annotation syntax is purely Python 3.x, so without
>>> some form of translation or import hook, 2.7 won't accept it. And
>>> adding a dependency (even if it's only a very lightweight typing.py
>>> plus a hook installed somewhere/somehow) for something that only has
>>> value as part of a developer-level type check doesn't seem like a good
>>> solution.
>>> 
>>> So, I'd like someone to explain (maybe by pointing me to relevant mypy
>>> docs, I haven't investigated them yet) how I should modify my existing
>>> code that supports 2.7 and 3.x so that it uses the new functionality
>>> *without* extra runtime dependencies that only deliver build/test-time
>>> benefits (that's the problem I always had with
>>> setuptools/pkg_resources, and I'd not like to see it repeated here).
>> 
>> I suspect the answer is "you don't". Just like everything else that is syntactically exclusive to Python 3, it's a perk you get with Python 3-only code that you simply can't get if you want to maintain backwards-compatibility. 

This seems like much more of an issue for libraries than for applications. It's not a big deal for an app to require Python 3.5, but most libraries out there are supporting, e.g., 2.7/3.3+, and I think that will continue for quite some time. You want your library to be useful to people whose apps are in 2.x and who don't yet have a compelling reason to port them, unless you're confident that your library in itself is compelling enough to be worth the effort and risk.

> 
> mypy does have a codec that will ignore annotations on 2.x. But other than that the answer is you don’t.

If the issue here is not wanting to create a new runtime dependency, that should be pretty easy to solve by just applying the codec at build time for 2.x installs. If the codec isn't easy enough to use from setup.py, that shouldn't be too hard to fix.

And maybe the codec (or equivalent functionality) could be added to setuptools, so it doesn't add an extra build-time dependency to most projects.

I realize that at first glance this sounds similar to saying "just run 2to3 or 3to2 at install time", which turned out to be unrealistic for many libraries. But the difference is that this is a very simple, specific transformation that should have no semantic impact on your runtime code, so I don't think it's naive to expect that it would be simple and reliable as a fully automated transformation.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140820/8664fc42/attachment-0001.html>