# Syntactic sugar "Beautiful is better than ugly, " thus nice syntax is needed. Current syntax is very mechanical. Syntactic sugar is needed on top of current PEP.
# internal vs external @intify def foo() -> int: b = "42" return b # check 1 x = foo() // 2 # check 2
Does the return type apply to implementation (str) or decorated callable (int)? How can same annotation or a pair of annotations be used to: * validate return statement type * validate subsequent use * look reasonable in the source code
# lambda Not mentioned in the PEP, omitted for convenience or is there a rationale? f = lambda x: None if x is None else str(x ** 2) Current syntax seems to preclude annotation of `x` due to colon. Current syntax sort of allows lamba return type annotation, but it's easy to confuse with `f`.
# local variables Not mentioned in the PEP Non-trivial code could really use these.
# global variables Not mentioned in the PEP Module-level globals are part of API, annotation is welcome. What is the syntax?
# comprehensions [3 * x.data for x in foo if "bar" in x.type] Arguable, perhaps annotation is only needed on `foo` here, but then how complex comprehensions, e.g. below, the intermediate comprehension could use an annotation [xx for y in [...] if ...]
# class attributes s = socket.socket(...) s.type, s.family, s.proto # int s.fileno # callable If annotations are only available for methods, it will lead to Java-style explicit getters and setters. Python language and data model prefers properties instead, thus annotations are needed on attributes.
# plain data user1 = dict(id=123, # always int name="uuu", # always str ...) # other fields possible smth = [42, "xx", ...] (why not namedtuple? b/c extensible, mutable) At least one PHP IDE allows to annotate PDO. Perhaps it's just bad taste in Python? Or is there a valid use-case?
# personal note I think it's amazing how much thought has already been put into this proposal. The foundation is pretty solid (per Guido talk). I am not at all opposed to software that infers types (like jedi), or reads user-specified types (like phpstorm and pep 484) and does something good with that. In fact I'm ambivalent to current proposal, standard and promise of better tools on one hand; narrow scope, debatable looks on the other.