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/
