[Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations (original) (raw)

Jack Diederich jackdied at gmail.com
Tue Aug 30 23:37:41 EDT 2016

On Tue, Aug 30, 2016 at 11:03 PM, Guido van Rossum <guido at python.org> wrote:

On Tue, Aug 30, 2016 at 7:44 PM, Jack Diederich <jackdied at gmail.com> wrote: > +0. We should try and be consistent even if this is a thing I don't want. > And trust me, I don't!

No problem. You won't have to! Yes! I don't have to want it, it is here!

> That said, as long as pro-mypy people are willing to make everyone else pay > a mypy reading tax for code let's try and reduce the cognitive burden. > > * Duplicate type annotations should be a syntax error. > Duplicate annotations aren't possible in functions so that wasn't an issue > in 484. 526 makes some things syntax errors and some things runtime errors > (for good reason -- function bodies aren't evaluated right away). > Double-annotating a variable is something we can figure out at compile time > and doing the double annotating is non-sensical so we should error on it > because we can.

Actually I'm not so sure that double-annotating is always nonsensical. In the mypy tracker we're seeing some requests for type inference that allows a variable to be given another type later, e.g. x = 'abc' testfunc(x) x = 42 anothertestfunc(x) Maybe there's a use for explicit annotations too. I would rather not get in the way of letting type checkers decide such semantics. Other languages (including rpython) don't allow rebinding types (or sometimes even re-assignment to same type). We are going for clarity [and bondage, and discipline]. If we are doing types let's do types like other people do. I think disallowing redefining the type is general to enforcing types. +1 on being consistent with other langs. If plain redoubling of types is allowed I'm OK "i: int = 0" doesn't summon horrors when said three times into a mirror. But we can't always know what "int" evaluates to so I'd just disallow it.

> * Dissallowing annotations on global and nonlocal > Agreed, allowing it would be confusing because it would either be a > re-definition or a hard to read annotation-at-a-distance. > > * Where annotations live > It is strange to allow modules.annotations and MyClass.annotations > but not myfunc.annotations (or more in line with existing function > implementations a myfunc.code.coannotations). If we know enough from > the syntax parse to have func.code.covarnames be known then we should > try to do that with annotations. Let's raise a SyntaxError for function > body annotations that conflict with same-named variables that are annotated > in the function signature as well.

But myfunc.annotations already exists -- PEP 3107 puts the signature annotations there. The problem with coannotations is that annotations are evaluated (they can be quite complex expressions, e.g. Optional[Tuple[int, int, somemod.SomeClass]]), while covarnames is just a list of strings. And code objects must be immutable. The issue with rejecting duplicate annotations so sternly is the same as for the previous bullet. If we disallow re-assignment of types as a syntax error then the conflict with myfunc.annotations goes away for vars that share a name with the function arguments. The fact that variables with types can't be known until the function body executes a particular line is .. I'm not sure how to deal with that. For modules and classes you can assert that the body at the top indent level has been executed. For functions you can only assert that it has been parsed. So myfunc.annotations could say that the type has a definition but only later know what the definition is.

I did C++ for years before I did Python and wrote C++ in many languages > (including Python). So ideally I'm -1000 on all this stuff for cultural > reasons -- if you let a C++ person add types they will for false comfort. > But again, I'm +0 on this specific proposal because we have already gone > down the garden path.

As long as you run mypy the comfort shouldn't be false. (But your starting with C++ before Python explains a lot. :-)

We've talked about this and we have different relationships with tools. I'm a monk who thinks using a debugger is an admission of failure; you think linters are a fine method of dissuading others of sin. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20160830/c9e7abfb/attachment.html>

More information about the Python-Dev mailing list