On Aug 13, 2014, at 7:43 PM, Guido van Rossum <guido@python.org> wrote:

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

On Aug 13, 2014, at 6:05 PM, Guido van Rossum <guido@python.org> wrote:

On Wed, Aug 13, 2014 at 1:53 PM, Donald Stufft <donald@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.

Understood! And really the most important thing I'm worried about isn’t that

there is some sort of code in the stdlib or in the interpreter just that there

is an authoritative source of what stuff means.

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. :-)

Depends on what is meant by "meaning" I suppose. Generally in those linters or

PyPy itself if there is a different *meaningful* result (for instance if

print was defaulting to sys.stderr) then CPython (incl docs) acts as the

authoritative source of what ``print()`` means (in this case writing to

sys.stdout).

I'm also generally OK with deferring possible code/interpreter changes to add

actual type checking until a later point in time. If there's a defined semantics

to what those annotations mean than third parties can experiment and do things

with it and those different things can be looked at adding/incorporating into

Python proper in 3.6 (or 3.7, or whatever).

Honestly I think that probably the things I was worried about is sufficiently

allayed given that it appears I was reading more into the vaguness and the

optionally different interpretations than what was meant and I don't want to

keep harping on it :) As long as there's some single source of what List[str]

or what have you means than I'm pretty OK with it all.