Python is DOOMED! Again!

Mario Figueiredo marfig at
Tue Jan 27 22:19:56 CET 2015

In article <mailman.18186.1422392925.18130.python-list at>, 
rosuav at says...
> On Wed, Jan 28, 2015 at 7:58 AM, Mario Figueiredo <marfig at> 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.
> ChrisA

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 mailing list