2021/08/11 19:22、Paul Moore <p.f.moore@gmail.com>のメール:
Also, I don't think that improving performance is a justification for a non-trivial backward compatibility break (I don't recall a case where we've taken that view in the past) so "PEP 649 solves forward references without a backward compatibility impact, and performance is a small issue in the face of that" is a reasonable position to take.
OK. I will stop talking about import time. But memory footprint and GC time is still an issue. Annotations in PEP 649 semantics can be much heavier than docstrings. So I want to measure them before deprecating 563. IMHO, I don't think we can make PEP 563 default anymore. FastAPI ecosystem changed how annotations are used after PEP 563 was accepted. So I think two or three options are on the table: a. Keep Python 3.10 state. PEP 563 is opt-in in foreseeable future. b. Accept PEP 649 and deprecate both of old semantics and PEP 563. c?. Accept PEP 649 and deprecate old semantics, but keep PEP 563 as opt-in. (I exclude "Accept PEP 649 but keep old semantics" option because backward compatibility is not a problem if we keep old semantics.) Of course, (b) is the most simple solution. But I am not sure that (b) don't have significant memory usage and GC time regression. We can keep (a) in Python 3.11 so we don't have to harry about accepting PEP 649. Regards,