On Wed, Aug 13, 2014 at 1:29 PM, Alex Gaynor <alex.gaynor@gmail.com> wrote:
I'm strongly opposed this, for a few reasons.
First, I think that standardizing on a syntax, without a semantics is incredibly confusing, and I can't imagine how having *multiple* competing implementations would be a boon for anyone.
That part was probably overly vague in my original message. I actually do want to standardize on semantics, but I think the semantics will prove controversial (they already have :-) and I think it's better to standardize the syntax and *some* semantics first rather than having to wait another decade for the debate over the semantics to settle. I mostly want to leave the door open for mypy to become smarter. But it might make sense to have a "weaker" interpretation in some cases too (e.g. an IDE might use a weaker type system in order to avoid overwhelming users with warnings).
This proposal seems to be built around the idea that we should have a syntax, and then people can write third party tools, but Python itself won't really do anything with them.
Right.
Fundamentally, this seems like a very confusing approach. How we write a type, and what we do with that information are fundamentally connected. Can I cast a ``List[str]`` to a ``List[object]`` in any way? If yes, what happens when I go to put an ``int`` in it? There's no runtime checking, so the type system is unsound, on the other hand, disallowing this prevents many types of successes.
Mypy has a cast() operator that you can use to shut it up when you (think you) know the conversion is safe.
Both solutions have merit, but the idea of some implementations of the type checker having covariance and some contravariance is fairly disturbing.
Yeah, that wouldn't be good. ;-)
Another concern I have is that analysis based on these types is making some pretty strong assumptions about static-ness of Python programs that aren't valid. While existing checkers like ``flake8`` also do this, their assumptions are basically constrained to the symbol table, while this is far deeper. For example, can I annotate something as ``six.text_type``? What about ``django.db.models.sql.Query`` (keep in mind that this class is redefined based on what database you're using (not actually true, but it used to be))?
Time will have to tell. Stubs can help. I encourage you to try annotating a medium-sized module. It's likely that you'll find a few things: maybe a bug in mypy, maybe a missing mypy feature, maybe a bug in your code, maybe a shady coding practice in your code or a poorly documented function (I know I found several of each during my own experiments so far).
Python's type system isn't very good. It lacks many features of more powerful systems such as algebraic data types, interfaces, and parametric polymorphism. Despite this, it works pretty well because of Python's dynamic typing. I strongly believe that attempting to enforce the existing type system would be a real shame.
Mypy shines in those areas of Python programs that are mostly statically typed. There are many such areas in most large systems. There are usually also some areas where mypy's type system is inadequate. It's easy to shut it up for those cases (in fact, mypy is silent unless you use at least one annotation for a function). But that's the case with most type systems. Even Haskell sometimes calls out to C. -- --Guido van Rossum (python.org/~guido)