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:

I agree with Alex that I think leaving the actual semantics of what these things

mean up to a third party, which can possibly be swapped out by individual end
users, is terribly confusing. I don’t think I agree though that this is a bad
idea in general, I think that we should just add it for real and skip the

indirection.

Yeah, I probably overstated the option of alternative interpretations. I just don't want to have to write a PEP that specifies every little detail of mypy's type checking algorithm, and I don't think anyone would want to have to read such a PEP either. But maybe we can compromise on something that sketches broad strokes and leaves the details up to the team that maintains mypy (after all that tactic has worked pretty well for Python itself :-).

IOW I'm not sure I see the benefit of defining the syntax but not the semantics

when it seems this is already completely possible given the fact that mypy
exists.

The only real benefits I can see from doing it are that the stdlib can use it,
and the ``import typing`` aspect. I don't believe that the stdlib benefits are

great enough to get the possible confusion of multiple different implementations
and I think that the typing import could easily be provided as a project on PyPI
that people can depend on if they want to use this in their code.

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.

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.

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 seperate Python interpreter

to actually do the run then I risk getting bad results through varying things

like interpreter differences, language level differences, etc.

Although I wouldn't complain if it meant that Python had actual type checking

at the run time if a function had type annotations :)

I'm fine to have a discussion on things like covariance vs. contravariance, or what form of duck typing are acceptable, etc.