On Tue, Aug 30, 2016 at 11:03 PM, Guido van Rossum <gu...@python.org> wrote:
> On Tue, Aug 30, 2016 at 7:44 PM, Jack Diederich <jackd...@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' > test_func(x) > x = 42 > another_test_func(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__.co_annotations). If we know enough > from > > the syntax parse to have func.__code__.co_varnames 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 co_annotations is that > annotations are evaluated (they can be quite complex expressions, e.g. > Optional[Tuple[int, int, some_mod.SomeClass]]), while co_varnames 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.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
