> 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
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/