<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 15 August 2014 23:18, Terry Reedy <span dir="ltr"><<a href="mailto:tjreedy@udel.edu" target="_blank">tjreedy@udel.edu</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="">
<br></div>
I claim that the mere presence of a decorator in the *source* is not enough. The decorator for non-type markers should do something with .__annotations__ -- in particular, remove the non-type markers.  The presence of a decorator in the source does not necessarily leave a trace on the returned function object for runtime detection.<div class="">

<br></div></blockquote><div><br></div><div>The way I understand it, mypy, which is what Guido's proposal sees its main potential user, operates at a stage similar to compilation in CPython. At which point anything after the colon in a parameter would be in its equivalent of __annotation__, regardless of what decorators add or remove. How would your other-annotation-removing decorator help mypy at all? By having it examine the decorator source and infer what kind of operation the decorator does? That doesn't sound very compile-stagey at all.</div>

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
To me, inspect.signature already assumes that annotations are about type, which means that this horse has already left barn. In 3.4.1:<br>
<br>
>>> from inspect import signature as sig<br>
>>> str(sig(nsqrt))<br>
"(n:(<class 'int'>, 'random non-type info')) -> (<class 'int'>, 'more non-type info')"<br>
<br></blockquote><div><br></div><div>`inspect.signature` makes no such assumption, it only relays what it found on the function's __annotation__ attribute. I don't know where this nsqrt function comes from, but it is responsible for having set up those annotations, which seem to be mere documentation if the "random non-type info" is a string.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
<br>
"the rule could be to ignore string annotations. Decorators can always eval, or perhaps safe_eval, strings."<br>
<br></div>
In other words, if type annotations were to be classes, as proposed, then non-type annotations should not be classes, so that pre-compile annotation consumers could easily ignore them. In particular, I suggested literal strings, which are easily recognized in source, as well as in asts.<br>


<br></blockquote><div><br></div><div>"Oh, everything that's not type-checking can be expressed in a string, maybe to be eval'ed, say, with sys,_getframe(-1) locals."</div><div><br></div><div>No, and that's incredibly ugly and may not work on alternate implementations of Python.</div>

<div><br></div><div>If a PEP is made to standardize typing attributes for annotations, perhaps in the form of a typing type hierarchy or a type decorator(ie. typing.Like(AClass)), or annotation namespacing of some sort(decorate the function with "hey! please typecheck me!"?), then couldn't tools that rely on those attributes pick out what's relevant to them on their own, thanks to the standardization?</div>

<div><br></div><div>I find the whole idea of having so far equal uses of function annotations be bullied aside for the good of a concept yet foreign to Python very arrogant and unnecessary.</div></div></div></div>