Hello, On Wed, 8 Jul 2020 13:15:19 -0400 David Mertz <me...@gnosis.cx> wrote:
> On Wed, Jul 8, 2020, 1:00 PM Paul Sokolovsky > > > Right. So, if someone would like to add something to this thread, > > I'd humbly suggest to concentrate on the lack of, and need for, of > > const-ness in the Python language core (in comparison to other > > languages or not), and usecases it enables, and not on criteria for > > "popularness". > > 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 (knowing they are not really const in Python or > bash, where I tend to use them). Roughly speaking, it's the same "gain" as e.g. (type) annotations. Indeed, const'ness is a kind of simple type annotation. > I think that clarifies intent in an important way. The talk is about formalizing specification of this intent beyond just stylistic conventions, like case of names. E.g.: def foo(): pass bar = foo # bar is a variable which stores a reference to a function # (can be reassigned with another function) baz: const = foo # baz is an alias for foo() > But checking it > feels like a job for linters, or perhaps for a future mypy or other > type checker. > > 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. If anything, lack of const in Python looks like an accidental gap (https://en.wikipedia.org/wiki/Accidental_gap): there're general annotations "with almost arbitrary" syntax, but there's no simple annotation with very obvious and useful semantics. There's support for "dict versions" (PEP 509), so you could catch cases when something was changed behind your back, and no means to say that something just should not change behind your back. There's a "meta-tracing" JIT and a number of failed corporate projects, and no means to develop a simple effective JIT, where user in control of making it more optimal (just mark things const and you don't need all those dict versions and runtimes guards, which take space in your instruction cache and put limit on how fast things can be). Finally, there's pattern matching PEP 622, which initially proposed a funny syntax, and now accidental-gap's matching by non-namespaced constants. All this gives feeling that Python skipped development of a simple and useful notion (const'ness, again), and its lack leads to more skips and unbeautiful workarounds with more complex features in the language. -- Best regards, Paul mailto:pmis...@gmail.com _______________________________________________ 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/X7QM5WVVPHZDJGX5TB4V2D3LQPOXD2MA/ Code of Conduct: http://python.org/psf/codeofconduct/