[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