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

[Jukka Lehtosalo]

On Mon, Aug 25, 2014 at 10:26 AM, Guido van Rossum <guido at python.org> wrote:

> On Mon, Aug 25, 2014 at 6:57 AM, Antoine Pitrou <antoine at python.org>
> wrote:
>
>> PEP 3107 doesn't say anything about that (or rather, it says that
>> annotations can be looked up on the function, but function objects only
>> exist at run-time). Actually, the bytecode isn't very practical to work
>> with to extract annotations,
>>
> I don't know at which point mypy changed goals (if it has), but there are
>> still signs in the website of the goal of building a separate runtime (not
>> necessarily a separate syntax), e.g.
>>
>> """Also some language features that are evaluated at runtime in Python
>> may happen during compilation in mypy when using the native semantics.
>> For example, mypy base classes may be bound during compilation (or
>> program loading, before evaluation), unlike Python."""
>>
>
> I have talked to Jukka about this, and he is definitely on board with
> reducing mypy's functionality to that of a linter; I think there's even an
> issue in mypy's tracker about removing the ability to execute the code
> (currently there's a flag you must pass to prevent it from trying to run
> the code). Updating the website is an ongoing low-priority project (you can
> probably send him pull requests for it).
>

Yeah, the website wasn't very up-to-date. The project goals have shifted a
lot in the last 18 months. I just updated the tutorial and the FAQ to not
talk about the native semantics.


> mypy complains about the unannotated initialization of sqs. The two ways
> to currently address this are
>
>     sqs = []  # type: List[float]
>
> or
>
>     sqs = List[float]()
>
> Neither is very attractive; mypy should just infer the type of sqs.
>

Agreed, but this is very difficult to do in all possible contexts. For
example, __init__ methods often use an empty list as an attribute
initializer, and here it's more tricky to infer the item type, as we'd have
to look into other methods to figure out the item type.


>
> Nevertheless, I don't want to use call syntax to set parameters for
> generic types, since a generic type still "feels" sufficiently like a class
> that calling it is easily confused with instantiation -- even though ABCs
> are typically not instantiable. (There's no hard rule for that though -- it
> is merely the result of typical ABCs having at least one abstract method.)
>

Generic types don't need to be abstract, and for those the call syntax
would be ambiguous (and confusing).

Jukka
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140825/bc194125/attachment.html>