[Python-ideas] PEP 563: Postponed Evaluation of Annotations, first draft
Ivan Levkivskyi
levkivskyi at gmail.com
Wed Sep 13 03:51:55 EDT 2017
> The difference in allocated memory is over 22 MB.
> The import time with annotations is over 2s longer.
> The problem with those numbers that we still have 80% functions to cover.
This will not be a problem with PEP 560 (I could imagine that string objects
may take actually more memory than relatively small cached objects).
Also I think it makes sense to mention in the PEP that stringifying
annotations
does not solve _all_ problems with forward references. For example, two
typical
situations are:
T = TypeVar('T', bound='Factory')
class Factory:
def make_copy(self: T) -> T:
...
and
class Vertex(List['Edge']):
...
class Edge:
ends: Tuple[Vertex, Vertex]
Actually both situations can be resolved with PEP 563 if one puts
`T` after `Factory`, and `Vertex` after `Edge`, the latter is OK, but
the former would be strange. After all, it is OK to pay a _little_ price
for Python being an interpreted language.
There are other situations discussed in
https://github.com/python/typing/issues/400, I don't want to copy all
of them to the PEP, but I think this prior discussion should be referenced
in the PEP.
> This is not a viable strategy since __future__ is not designed to be
> a feature toggle but rather to be a gradual introduction of an upcoming
> breaking change.
But how it was with `from __future__ import division`? What I was proposing
is something similar, just have `from __future__ import annotations` that
will
be default in Python 4. (Although this time it would be a good idea to emit
DeprecationWarning one-two releases before Python 4).
--
Ivan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20170913/6d364b39/attachment.html>
More information about the Python-ideas
mailing list