> > annotate.accepts(int, (int,float)) > > I don't understand. How are you changing/annotating the function? I'm glad you asked. My suggestion was that the compiler turn annotate.accepts(int, (int,float)) into exactly what it would have turned @accepts(int, (int,float)) into. I hope I am not being incredibly stupid, but I am thinking only of syntax here. So wherever the community would have decided to put: @accepts <<whatever>> the new "syntax" would be: annotate.accepts <<whatever>> Do you see? The annotate "module" probably doesn't exist at all. I think of it as a pseudo-module. That's why I wrote "from __future__ import annotation as annotate" in the original post. My thinking is this: apparently people like the @ syntax. Why not do some magic and compile module references to the annotation pseudo-module just as it is presently proposed to compile the @ syntax. That way we don't change the apparent syntax at all, we use the annotation namespace to denote what is happening, and we use annotate.x exactly as we would have used @x. Again, my thinking is that this would be completely independent of the other choices about where to use @. Wherever the consensus is, then use the annotation pseudo-module there. Have I made myself clear? Edward P.S. I wrote: from __future__ import annotation as annotate as a hint that one could write: from __future__ import annotation as a if brevity is important. Then we would write a.accepts instead of @accepts. EKR -------------------------------------------------------------------- Edward K. Ream email: edreamleo at charter.net Leo: Literate Editor with Outlines Leo: http://webpages.charter.net/edreamleo/front.html --------------------------------------------------------------------
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4