[Python-Dev] Please reject or postpone PEP 526 (original) (raw)
Guido van Rossum guido at python.org
Tue Sep 6 12:22:46 EDT 2016
- Previous message (by thread): [Python-Dev] Please reject or postpone PEP 526
- Next message (by thread): [Python-Dev] Please reject or postpone PEP 526
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Tue, Sep 6, 2016 at 9:00 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
On 6 September 2016 at 14:04, Guido van Rossum <guido at python.org> wrote:
I'm sorry, but we're not going to invent new syntax this late in the game. The syntax proposed by the PEP has been on my mind ever since PEP 484 with very minor variations; I first proposed it seriously on python-ideas over a month ago, we've been debating the details since then, and it's got a solid implementation based on those debates by Ivan Levkivskyi. In contrast, it looks like you just made the "assert x: T" syntax up last night in response to the worries expressed by Mark Shannon, and "assert" sounds a lot like a run-time constraint to me. That's a fair description, but the notation also helped me a lot in articulating the concepts I was concerned about without having to put dummy annotated functions everywhere :)
Thanks Nick! It seems your writings has helped some others (e.g. Ethan) understand PEP 526.
Instead, I encourage you to participate in the writing of a separate PEP explaining how type checkers are expected to work (since PEP 526 doesn't specify that). Ivan is also interested in such a PEP and we hope Mark will also lend us his expertise. Aye, I'd be happy to help with that - I think everything proposed can be described in terms of existing PEP 484 primitives and the descriptor protocol, so the requirements on typecheckers would just be for them to be self-consistent, rather than defining fundamentally new behaviours.
Beware that there are by now some major type checkers that already claim conformance to PEP 484 in various ways: mypy, pytype, PyCharm, and probably Semmle.com where Mark works has one too. Each one has some specialty and each one is a work in progress, but a PEP shouldn't start out by declaring the approach used by any existing checker unlawful.
As an example, mypy doesn't yet support Optional by default: it
recognizes the syntax but it doesn't distinguish between e.g. int and
Optional[int]. (It will do the right thing when you pass the
--strict-optional
flag, but there are still some issues with that
before we can make it the default behavior.)
As another example: mypy understands isinstance() checks so that e.g. the following works:
def foo(x: Union[int, str]) -> str: if isinstance(x, str): return x return str(x)
I don't think you can find anything in PEP 484 that says this should work; but without it mypy would be much less useful. (The example here is silly, but such code appears in real life frequently.)
One final thought: this is not the first time that Python has used
syntax that looks like another language but gives it a different
meaning. In fact, apart from if
, almost everything in Python works
differently than it works in C++ or Java. So I don't worry much about
that.
-- --Guido van Rossum (python.org/~guido)
- Previous message (by thread): [Python-Dev] Please reject or postpone PEP 526
- Next message (by thread): [Python-Dev] Please reject or postpone PEP 526
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]