Python is DOOMED! Again!
marfig at gmail.com
Tue Jan 27 22:19:56 CET 2015
In article <mailman.18186.1422392925.18130.python-list at python.org>,
rosuav at gmail.com says...
> On Wed, Jan 28, 2015 at 7:58 AM, Mario Figueiredo <marfig at gmail.com> wrote:
> > Looking at PEP 3107, i'm left wondering: what if I have for instance
> > already annotated my functions for parameter marshalling, following the
> > syntax expected of that specific library, and now I want to annotate
> > them for type hinting for the purposes of static analysis?
> This is the kind of argument that keeps on coming up. Everyone has a
> "What if" scenario about function annotations... and almost nobody
> actually has a codebase that uses them. It's equivalent to asking:
> "What if I already used docstrings to control URL routing, and now I
> want to use them for function documentation?". Well, simple. You move
> your other-use-of-annotations out to something else (probably a
> decorator) before you add type hints. Until that time, you're welcome
> to continue using annotations for something other than type hinting;
> you just can't do both at once on the same function.
I'm sorry Chris. But that's a weak argument and you know it. If I use
those decorators inside properly formated docstrings, I can do both
things, and more! And I don't have to move anything anywhere.
def func(a, b, c):
This function does something very interesting and returns a surprise
:a: an integer, also known as whole number (lies!)
:b: a float on a string so it can't escape
:c: an unicode string with some bad language
@typehint@ some crazy syntax for static analysis
@marshallib@ more crazy syntax for the marshall lib
@anotherlib@ Whoohoo! a 3rd annotation for another lib
Are you telling me this is not a viable alternative. That somehow we
should ignore the possibility of potentially different annotations
having to coexist on a project? C'mon!
More information about the Python-list