On Wed, Jul 8, 2020, 1:50 PM Paul Sokolovsky > > I admit I do not really understand what gain dynamic languages get from > constants. I pretty uniformly use a common convention of ALLCAPS for > constant names > > > I can easily imagine that a VM might gain speed with that information, > but that alone does not feel like enough reason for a language change. > > If people are satisfied with Python's performance story as presented by > CPython, perhaps. Because otherwise, having a formal constants in the > code allows for simple and obvious optimizations: instead of looking up > value by name at runtime, you can use literal value at the compile time. >
Most "obvious" optimizations in the history of Python have not wound up speeding up CPython. If you have a fork that can convince Victor of a noteworthy speed up, my perspective would definitely shift. Stipulating such a win exists (and amounts to more than 1-2%), deciding syntax would be the next question. My personal feeling would be that enshrining the ALLCAPS convention would be nice. That could potentially make existing code become magically faster. Of course, not all code uses that convention, and some violates the constant-ness only sometimes. So deprecation periods and __future__ import, etc.
_______________________________________________ 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/Z74N67QHYO7HQ2DVQERIFQSDC3YAVEZO/ Code of Conduct: http://python.org/psf/codeofconduct/
