<div class="gmail_extra"><br><br><div class="gmail_quote">On 30 November 2012 12:49, Robert McGibbon <span dir="ltr">&lt;<a href="mailto:rmcgibbo@gmail.com" target="_blank">rmcgibbo@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>I don&#39;t use python3. (I would, but I depend on PyTabes for everything, and it isn&#39;t py3k ready). Without the</div><div>syntactical support, manually attaching __annotations__ to functions seems like a lame api.</div>

</blockquote><div><br>It would be quite easy to write a decorator (@annotations perhaps) that would take care of handling __annotations__ for you, like this:<br><br>@annotate(a=tab(&#39;foo&#39;), b=int)<br>def myfunc(a, b=1):<br>

    ...<br><br>Then frameworks using annotations could keep working seamlessly as downstream code transitions to:<br><br>def myfunc(a:tab(&#39;foo&#39;), b:int =5):<br>   ...<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>Second, in order to do annotations &quot;right&quot; in such a way that two independent project don&#39;t have annotation semantics</div><div>that fail to interoperate, everyone needs to agree on some system. If one library expects the annotations to be strings</div>

<div>(or to mean a  specific thing, like a type for typechecking) and another library expects something different, then everyone is</div><div>in a bad spot. <a href="http://www.python.org/dev/peps/pep-3107/" target="_blank">PEP3107</a> seems to want some convention to &quot;develop organically&quot;.</div>

</blockquote><div><br>I agree that this is somewhat awkward. But I think a convention will have to develop where frameworks ignore annotations they don&#39;t understand. As a starting set of rules, it seems sensible that:<br>

<br>- Annotations that are built-in types (e.g. int) will indicate some kind of variable contract, so the associated parameter should always be of that type.<br>- Annotations that are strings will be used like docstrings.<br>

<br>I suggest all more advanced uses involve some sort of wrapper, like tab() in your examples. Frameworks that don&#39;t recognise the wrapper will ignore the contents.<br><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div><font face="Courier"></font></div><div>(2). Inspired by <a href="https://en.wikipedia.org/wiki/Ggplot2" target="_blank">ggplot</a>, where you compose plots by <u>summing</u> components, the annotations could be the sum of</div>

<div>objects that overload <font face="Courier">__add__</font>, like:</div></blockquote><div><br>This looks nice! I&#39;d also thought of the dictionary idea, but it does make code ugly.<br><br>I&#39;d implement it slightly differently, though - instead of a linked list, I&#39;d make __add__ return a container object, so you could add things like strings (so long as they&#39;re not in first place):<br>

<br>def my_io(fname, mode: tab(&#39;read&#39;,&#39;write&#39;) + &quot;The mode in which to open the file&quot;):<br>     ...<br><br>I think it&#39;s worth floating these ideas in a more general Python forum, so we can get feedback from other people thinking about using annotations.<br>

<br>Thomas<br></div></div><br></div>