<div class="gmail_quote">On Sun Jan 18 2015 at 3:16:47 PM Chris Angelico <<a href="mailto:rosuav@gmail.com">rosuav@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Jan 19, 2015 at 12:37 AM, Cem Karan <<a href="mailto:cfkaran2@gmail.com" target="_blank">cfkaran2@gmail.com</a>> wrote:<br>
> There may be other uses of annotations that programmers haven't yet thought of, simply because they don't know that annotations exist.  Locking out those uses would suck.<br>
<br>
I see a lot of vague "but what if there's something else", and not a<br>
lot of concrete "here's a use of annotations that would be locked<br>
out". Does anyone actually have another use case that would be<br>
seriously harmed by this kind of conflict?</blockquote><div><br></div><div><div style="font-size:13.1999998092651px;line-height:19.7999992370605px">I use annotations in clize, a CLI argument parser, to specify how functions parameters should translate to CLI parameters. This can range from specifying coercion functions/callables for the argument values(ie. int), which could easily be mixed up with typing information as specified here, to specifying aliases for named parameters, marking parameters as undocumented, or simply overriding the translation process altogether for that parameter.</div><div style="font-size:13.1999998092651px;line-height:19.7999992370605px"><br></div><div style="font-size:13.1999998092651px;line-height:19.7999992370605px">Now I could simply instruct users to never use annotations and always use a decorator instead (in fact, I recommend it when Python 2.x compatibility is wished) and have that decorator dump this information elsewhere than in f.__annotations__, but that begs the question of why it isn't as worthy of benefiting from annotation syntax[1] as type-checking. If anything, this is a use of annotations at run-time versus a use at dev-time in an offline fashion.</div><div style="font-size:13.1999998092651px;line-height:19.7999992370605px"><br></div><div style="font-size:13.1999998092651px;line-height:19.7999992370605px">I also find it a bit hasty to proclaim no one has found other viable uses for annotations when Python 3 adoption and thus liberty to use annotations still remains poor.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Remember, you can simply<br>
not use type hints for the function(s) that use other annotations; the<br>
conflict is only if you're trying to use both on the same function.<br></blockquote><div><br></div><div><div style="font-size:13.1999998092651px;line-height:19.7999992370605px"><div class="F3hlO"><div class="gmail_quote"><div>If typing is to become the default interpretation of annotations, I fear that this will really just turn into "WTF, your annotations aren't type info, fix it", especially given the recursive nature of those checks.</div><div><br></div><div>Why can't it be explicit that a function's annotations are type info that should be checked? "typing.check(func)", "@typing.check   def func(...):", "import typing; typing.check_all()", "import typing" not followed by "typing.nevermind()", anything?</div><div><br></div><div><br></div><div><br></div><div>[1] I guess I could write a decorator that moves annotations out of __annotations__ into another dict, but I'm not sure that would be relevant at all to a *static* analyzer which wouldn't have to care what dict things end up in. Again, illustrates the weirdness of having this run-time feature be reserved for static analysis.</div><div><br></div></div></div></div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
ChrisA<br>
______________________________<u></u>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" target="_blank">https://mail.python.org/<u></u>mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" target="_blank">http://python.org/psf/<u></u>codeofconduct/</a><br>
</blockquote></div>