[Python-Dev] What's missing in PEP-484 (Type hints)

Dima Tisnek dimaqq at gmail.com
Thu Apr 30 13:41:53 CEST 2015


# 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.


-- dima


More information about the Python-Dev mailing list