[Python-ideas] PEP 484 (Type Hints) -- first draft round
greg.ewing at canterbury.ac.nz
Wed Jan 21 23:18:28 CET 2015
Guido van Rossum wrote:
> That's debatable. While evaluating them at run time causes some issues
> with forward references (mostly for container-ish class definitions), it
> also catches many mistakes early, such as not importing the referenced
Wouldn't the static type checker catch that even earlier?
If you reference something in a type expression that you
haven't imported, the static checker won't know what it
means, so surely it must complain.
> Switching to a double colon
> would make it a magical operator -- especially since a single colon in
> the same position would have a similar but different meaning.
I don't see how it's any more magical than '==' being a
distinct token rather than just two '=' tokens in a row,
and 'x == 2' having a different meaning from 'x = 2'.
> Eight years ago we picked the winning syntax for argument
> annotations. It would be tragic if we now were to replace it with this
> syntactic hack.
I think it's tragic that we seem to have painted ourselves
into a corner where we can't give that winning syntax the
semantics that would be best for what we've now decided on
as the winning use case.
How about we just deprecate relying on run-time evaluation
of argument annotations? You've pretty much declared that
all existing uses of them are deprecated, so it wouldn't
cause much more breakage in the long run, and it would give
us a way out of the corner in the future if we wanted.
More information about the Python-ideas