On Aug 20, 2014, at 7:25, Donald Stufft
On Aug 20, 2014, at 10:11 AM, Brett Cannon
wrote: On Wed Aug 20 2014 at 9:29:34 AM Paul Moore
wrote: On 14 August 2014 00:30, Guido van Rossum
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.