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

[Guido van Rossum]

On Wed, Aug 13, 2014 at 3:44 PM, Donald Stufft <donald at stufft.io> wrote:

> On Aug 13, 2014, at 6:05 PM, Guido van Rossum <guido at python.org> wrote:
>
> On Wed, Aug 13, 2014 at 1:53 PM, Donald Stufft <donald at stufft.io> wrote:
>>
>>
>> So my vote would be to add mypy semantics to the language itself.
>>
>
> What exactly would that mean? I don't think the Python interpreter should
> reject programs that fail the type check -- in fact, separating the type
> check from run time is the most crucial point of my proposal.
>
>
> I don’t know exactly :)
>
> Some ideas:
>
> 1) Raise a warning when the type check fails, but allow it happen. This
> would
>    have the benefit of possibly catching bugs, but it's still opt in in the
>    sense that you have to write the annotations for anything to happen.
> This
>    would also enable people to turn on enforced type checking by raising
> the
>    warning level to an exception.
>

I don't think that's going to happen. It would require the entire mypy
implementation to be checked into the stdlib. It would also require all
sorts of hacks in that implementation to deal with dynamic (or just
delayed) imports. Mypy currently doesn't handle any of that -- it must be
able to find all imported modules before it starts executing even one line
of code.


>    Even if this was off by default it would make it easy to enable it
> during
>    test runs and also enable easier/better quickcheck like functionality.
>

It would *have* to be off by default -- it's way too slow to be on by
default (note that some people are already fretting out today about a 25
msec process start-up time).


> 2) Simply add a flag to the interpreter that turns on type checking.
>
> 3) Add a stdlib module that would run the program under type checking, like
>    ``python -m typing myprog`` instead of ``python -m myprog``.
>
> Really I think a lot of the benefit is likely to come in the form of
> linting
> and during test runs. However if I have to run a separate Python
> interpreter
> to actually do the run then I risk getting bad results through varying
> things
> like interpreter differences, language level differences, etc.
>

Yeah, but I just don't think it's realistic to do anything about that for
3.5 (or 3.6 for that matter). In a decade... Who knows! :-)


> Although I wouldn't complain if it meant that Python had actual type
> checking
> at the run time if a function had type annotations :)
>

It's probably possibly to write a decorator that translates annotations
into assertions that are invoked when a function is called. But in most
cases it would be way too slow to turn on everywhere.

> I'm fine to have a discussion on things like covariance vs.
> contravariance, or what form of duck typing are acceptable, etc.
>
> I’m not particularly knowledgable about the actual workings of a type
> system and
> covariance vs contravariance and the like. My main concern there is having
> a
> single reality. The meaning of something shouldn't change because I used a
> different interpreter/linter/whatever. Beyond that I don't know enough to
> have
> an opinion on the actual semantics.
>

Yeah, I regret writing it so vaguely already. Having Alex Gaynor open with
"I'm strongly opposed [to] this" is a great joy killer. :-)

I just really don't want to have to redundantly write up a specification
for all the details of mypy's type checking rules in PEP-worthy English.
But I'm fine with discussing whether List[str] is a subclass or a
superclass of List[object] and how to tell the difference.

Still, different linters exist and I don't hear people complain about that.
I would also be okay if PyCharm's interpretation of the finer points of the
type checking syntax was subtly different from mypy's. In fact I would be
surprised if they weren't sometimes in disagreement. Heck, PyPy doesn't
give *every* Python program the same meaning as CPython, and that's a
feature. :-)

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140813/94e4cfaa/attachment.html>