[Python-ideas] Proposal: Use mypy syntax for function annotations

[Antoine Pitrou]

Le 23/08/2014 01:13, Steven D'Aprano a écrit :
> On Fri, Aug 22, 2014 at 10:31:18PM -0400, Antoine Pitrou wrote:
>
>>>> Python has one of the most powerful and user-friendly function call
>>>> syntaxes around, why reinvent something clearly inferior and alien?
>>>
>>> I wouldn't say it is alien. abc[xyz] is clearly Python syntax.
>>
>> But it is completely uncommon for anything else than subscripting and
>> indexing containers.
>
> And function call syntax is completely uncommon for anything else than
> calling functions (including types and methods). One way or the other,
> we're adding a new use, type declarations.

It's not a new use. A type class is a class, and calling it is just 
instantiating that class. There's nothing new here. If you think that's 
a bit "meta", it's no different than e.g. higher-order functions.

>> Python isn't known for reusing operators for
>> completely unrelated things, e.g. it doesn't overload ">>" for I/O
>> (thank goodness).
>
> I see you've forgotten Python 2's
>
>      print >>sys.stderr, x, y, z
>
> :-)

I always forget about it, but the fact that we finally made print() a 
function in Python 3 actually supports my point: we had a special case, 
and we had to remove it - breaking compatibility in the process - 
because it was impeding on extensibility (adding keyword-only arguments) 
and flexibility (swapping out print() with another function).

"The brackets looks better" is a misguided argument, the same way the 
idea that "print" was cuter as a non-parenthetical statement (and that 
we wouldn't need the power of a regular function call; eventually we 
*did* need it) was a misguided argument.

> The
> annotations themselves will remain arbitrary Python expressions, so if
> you really need a complex type declaration, you can create a helper and
> call it with whatever signature you like.[1]

I don't think you understand what this discussion is about. It isn't 
only about annotations (they are only the channel used to convey the 
information), it is about standardizing a typing system in the stdlib - 
and, therefore, accross the Python community.

I want the *default* typing system to be extensible (not by me, but by 
the community, because use cases for that *will* arise). I would want 
the same thing even if the proposal was to use something else than 
annotation to convey type descriptions.

> I can't speak for the author of mypy, Jukka Lehtosalo, but for me, I
> think the answer is that type declarations make a *mini-language*, not
> full-blown Python.

No, the answer is that mypy wants to support runtime instantiations of 
its type descriptions. It wants to allow you to write e.g. "List[Int]()" 
to instantiate a regular Python list.

While that's one of mypy's design points, though (because mypy 
ultimately seems to aim at becoming a separate Python dialect), it's not 
desired for regular Python.

> It is unclear to me just how powerful the type
> language will be, but surely we don't expect it to evaluate arbitrarily
> complex Python expressions at compile time? Do we?

Why wouldn't it? Ideally, "compile time" is just the import of the module.
(yes, some libraries are ill-behaved on import; they break pydoc and the 
like; I'd say it's their problem)

> I find it unlikely that we expect a static linter to make sense of this:
>
> def bizarre(param:int if random.random() > 0.5 else str)->float:

Yeah... so what, exactly? Do you also criticize Python because it allows 
you to write absurd code? Does it make Python "too powerful"?

> So:
>
> - how powerful do we expect the type system to be?

This is a bad question to ask. That's like asking "how powerful does a 
function or decorator need to be?" The entire point of devising new 
language or library tools is to enable use cases that we *don't know 
about yet*.

I'm not the only one pointing this out. Other people have also come with 
examples where they'd like to make the type system more powerful. And 
that's right now. The future will see more interesting propositions, the 
same way decorators grew to a mechanism powering very diverse and 
sophisticated use cases.

Saying "I don't want to make this functionality powerful because I can't 
think of powerful use cases" is the mentality that leads to things such 
as PHP (closures? functions as objects? "why would I need that to write 
Web pages?").

> - and how much of that power needs to be expressed using
>    function annotations?
 >
> The second question is critical, because there are alternatives to
> function annotations: decorators, docstring annotations, and external
> stub files.

Why would those other channels use a type description syntax different 
from the one used in function annotations? That would be crazy.

You seem to think that a type system should simply be some kind of 
textual description. It's not. It's a set of objects (or classes) with 
some behaviour attached to them; that's why it uses Python syntax. 
Because it *is* Python code.

Regards

Antoine.