29.11.21 18:36, Victor Stinner пише: > You should consider "no longer have to justify why it's not optimized" > as a clear benefit of making this change :-) This optimization is > proposed once a year for many years... > > For me, any possible compilation-ahead optimization (which doesn't > break the Python semantics) is worth it ;-) It's done once, possible > even before the program is run for the first time, and then makes the > code faster.
I consider the cost of rejecting such idea (this is actually the first time it was pushed so persistent) less than the cost of implementing and maintaining it. The proposed PR adds around 200 lines of code. It is almost 20% of the current size of ast_opt.c, it is not small. And just at first look I see a flaw in it -- it will emit a BytesWarning when compare strings and bytes. After fixing this the size will grow even more. And there may be other issues with this code which will be found months later. Later, when we rewrite the optimizer or change the structure of AST we will need to update this code too, with possibility to introduce new bugs. On other hand, the benefit of this optimization is exact zero. It does not make code faster, because it optimizes the code not used in real programs. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/LOIK6ZX43QHQSNWWUSE6YE3O5YBVGJOM/ Code of Conduct: http://python.org/psf/codeofconduct/
