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