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

[Donald Stufft]

> On Aug 13, 2014, at 4:29 PM, Alex Gaynor <alex.gaynor at 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.
> 
> 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.
> 
> 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.
> 
> Both solutions have merit, but the idea of some implementations of the type
> checker having covariance and some contravariance is fairly disturbing.
> 
> 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 somethign 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))?
> 
> 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.
> 
> Alex
> 
> PS: You're right. None of this would provide *any* value for PyPy.
> 
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/


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.

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.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

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