Introduce constant variables in Python

Many times a programmer would want a variable that will be a constant. The programmer could have been careless and suddenly changed a very important variable. Proposed syntax, constant variable = 10 variable = 20 # Error Now constant means making a variable value immutable. It means now we can neither change the variable to point to another value nor the value itself anymore. For example, if we have a list we cannot change it. If we try to then "Error". So for lists, constant variable = ["List"] variable.append("Some") # Error variable = ["Another"] # Error Usually if we have a constant we don't create another reference to it. So do not support two references. Why not? Many reasons, especially deallocation problems. Thanking you, With Regards

Greetings, Just a light-hearted note, if ever the idea is taken seriously, variable: constant = 10 seems more pythonic to me. constant variable = 10 opens the doors for int x = 5 etc Kind Regards, Abdur-Rahmaan Janhangeer about <https://compileralchemy.github.io/> | blog <https://www.pythonkitchen.com> github <https://github.com/Abdur-RahmaanJ> Mauritius

typing.Final actually means something like "cannot be reassigned", whereas constant variable means "cannot change". Consider e.g. class Spam: def __init__(self): self.eggs = 0 @final # method cannot be overridden (which is more related to "reassignment" than to "change") def more(self): self.eggs += 1 spam: Final[Spam] = Spam() spam.more() # This is allowed, but spam changed del spam # Allowed as well Moreover, `Final` is part of typing, which is strange because it indicates a property of the variable name itself, not of its type. Perhaps the constant keyword can become a replacement for the confusing `typing.Final`. So "constant" is semantically different than `typing.Final` (and `typing.final`), and it makes more sense to have it be a keyword (e.g. `constant spam`), instead of it being an annotation; it only should be used when declaring variables and attributes (e.g. `def f(a: Final)` is not allowed).

On Tue, May 25, 2021 at 7:30 AM Joren <jhammudoglu@gmail.com> wrote:
What's the definition of "cannot change"? Which of these counts as a change? x = (42, ["spam"]) x[1][0] = "ham" # This? lst = ["spam"] y = (42, lst) lst[0] = "ham" # This? r = random.Random() r.randrange(10) # This? class C: pass class D(C): pass # Is this changing X? x is a tuple, and we already know that they're immutable. Yet its value changed when something else changed. In y's case, the assignment never even mentions the tuple, yet y's value still changes. The Random instance has internal state which changes every time you ask for a random number. And you can ask a class for all of its subclasses, so the detectable behaviour of it changes when you add a new subclass. Requiring that a name not be rebound is well-defined and testable. Requiring that an object not change is either trivial (in the case of, say, an integer) or virtually impossible (in the case of most objects). What would be the advantage of such a declaration? ChrisA

We could define "change" in terms of the hash of the object the name points to, as well as the name itself (the pointer to the object).

On Tue, May 25, 2021 at 8:09 AM Joren <jhammudoglu@gmail.com> wrote:
We could define "change" in terms of the hash of the object the name points to, as well as the name itself (the pointer to the object).
The hash of a random.Random() object doesn't change when its state does (its derived solely from its id). Nor does the hash of a class. Nor an instance of a class defined simply as "class Thing: pass". ChrisA

On Mon, May 24, 2021 at 5:43 PM Chris Angelico <rosuav@gmail.com> wrote:
What would be the advantage of such a declaration?
ChrisA
## Existing threads re: consts and applications thereof So, `/? from:me pyrsistent` I found a few results: - "[Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)" 2016-04 https://mail.python.org/pipermail/python-dev/2016-April/143958.html - ~Sandboxing python within python is nontrivial to impossible; consts might help a bit - https://mail.python.org/pipermail/python-dev/2016-April/143958.html - "Proposal to add const-ness type hints to PEP-484" https://mail.python.org/archives/list/python-ideas@python.org/thread/OVPF5I6... - https://github.com/python/typing/issues/242 - "Final names and attributes" https://github.com/python/mypy/pull/5522 This is where `typing.Final` comes from. - "[Python-ideas] "Immutable Builder" Pattern and Operator" https://mail.python.org/pipermail/python-ideas/2017-January/044374.html - [pyrsistent] and "fn.py [do] immutables: https://github.com/kachayev/fn.py/blob/master/README.rst#persistent-data-str... " - "[Python-ideas] Add recordlcass to collections module" https://groups.google.com/g/python-ideas/c/9crHfcCBgYs/m/6_EEaWJAAgAJ - ORMs (e.g. Django, SQLAlchemy) require "dirty state" checking to know which object attributes have changed and need an SQL statement to be executed to synchronize the state; this is relevant because when we're asking for mutable namedtuple we're often trying to do exactly this pattern. - "[Python-ideas] Suggestions: dict.flow_update and dict.__add__" https://www.google.com/search?q=%22%5BPython-ideas%5D+Suggestions%3A+dict.fl... precedes dataclasses. pyrsistent also has 'freeze' and 'thaw' functions for immutability. PRecord extends PMap, which implements __add__ as self.update(arg) (which does not mutate self) https://github.com/tobgu/pyrsistent/blob/master/README.rst#precord
https://github.com/tobgu/pyrsistent/blob/master/pyrsistent/_pmap.py
PyArrow Plasma object ids, "sealing" makes an object immutable,
- "[Python-ideas] How to prevent shared memory from being corrupted ?" https://www.google.com/search?q=%22How+to+prevent+shared+memory+from+being+c... pyristent
https://arrow.apache.org/docs/python/plasma.html#creating-an-object-buffer
- [Python-ideas] Experimenting with dict performance, and an immutable dict https://mail.python.org/archives/list/python-ideas@python.org/message/DNBGUJ... throughout its lifetime and need not worry that somewhere five stack levels below you in the darkest corner of your application someone has decided to remove that element that you expected to be there.
What would be the advantage of such a declaration?
Constants don't need to be locked or unlocked; which is advantageous for parallelism and reasoning about program correctness. True consts (wherein everything referred to in that object is 'frozen' and immutable or at least only modifiable with e.g. copy-on-write) wouldn't require locks, which would be post-GIL advantageous. You could do consts by never releasing a threading.Lock (or similar): - https://docs.python.org/3/library/asyncio-sync.html#locks - https://docs.python.org/3/library/threading.html#lock-objects - This from https://docs.python.org/2/library/sets.html?highlight=immutable#immutable-tr... re ImmutableSet/FrozenSet is not present in the python 3 docs: https://docs.python.org/3/library/stdtypes.html#set-types-set-frozenset Though - even if Python enforced normal consts in the language - all of the other code objects would still be mutable, so you still have the impossibility of sandboxing python. Functional and contracts coding styles rely upon invariance; which can be accomplished with various third-party packages that enforce const-ness throughout what may be an object tree behind that reference that would otherwise need to be copy.deepcopy()'d. ## pyrsistent Src: https://github.com/tobgu/pyrsistent
collections and pyrsistent collections. > - Flexible transformations of arbitrarily complex structures built from PMaps and PVectors.
## icontract Src: https://github.com/Parquery/icontract
https://en.wikipedia.org/wiki/Design_by_contract https://en.wikipedia.org/wiki/Invariant_(mathematics)#Invariants_in_computer... [ https://en.wikipedia.org/wiki/Class_invariant ] What is the difference between "invariant" and "constant" and "final"?

On Fri, Jun 18, 2021 at 12:43 AM Wes Turner <wes.turner@gmail.com> wrote:
That only works if you have a garbage collector that doesn't depend on reference counts (as CPython's does). Otherwise, you still need to modify the object, in a trivial sense, every time a reference is added or removed. ChrisA

On Thu, Jun 17, 2021 at 10:50 AM Chris Angelico <rosuav@gmail.com> wrote: > On Fri, Jun 18, 2021 at 12:43 AM Wes Turner <wes.turner@gmail.com> wrote: > > > > > What would be the advantage of such a declaration? > > > > Constants don't need to be locked or unlocked; which is advantageous for > parallelism and reasoning about program correctness. > > True consts (wherein everything referred to in that object is 'frozen' > and immutable or at least only modifiable with e.g. copy-on-write) > > wouldn't require locks, > > which would be post-GIL advantageous. > > > > That only works if you have a garbage collector that doesn't depend on > reference counts (as CPython's does). Otherwise, you still need to > modify the object, in a trivial sense, every time a reference is added > or removed. > - https://pythoncapi.readthedocs.io/gilectomy.html > Gilectomy is Larry Hastings’s project to attempt to remove the GIL from CPython. It a fork on CPython which uses lock per object rather than using a Global Interpreter Lock (GIL). - https://lwn.net/Articles/754577/ Update re: Gilectomy - There's probably a doc somewhere listing all of the post-GIL works? (Consts could be a helpful performance optimization for like all of the approaches I've seen) - https://lwn.net/Articles/754162/ Subinterpreters PEP > The PEP provides for a shared-nothing concurrency model. It has a minimal Python API in an interpreters module. It also adds channels to pass immutable objects between interpreters. A subinterpreter will retain its state, so the interpreter can be "primed" with modules and other setup in advance of its use. https://www.python.org/dev/peps/pep-0554/#a-disclaimer-about-the-gil https://distributed.dask.org/en/latest/memory.html#clearing-data > > ChrisA > _______________________________________________ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-leave@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/BZ5WQZP5BSJEO3FY2H4DK4RLDHZBOO3M/ > Code of Conduct: http://python.org/psf/codeofconduct/ >

"Constant variables" is a contradiction in terms. If it is constant, it cannot be a variable, and vice versa. Can we be more precise in the language used please? We have two independent concepts here: * name bindings: names can be bound to a value, or unbound with the `del` statement; * values can be mutable or immutable. "Constant" might refer to immutability. `1` is a constant, but `[]` is not, because the list can be mutated. In some languages (not Python), we can "freeze" a mutable object and turn it immutable. Or it might refer to bindings: a perhaps a constant name cannot be unbound or rebound to a new object, but the object may be either mutable or immutable. Can you explain what combination of these three features (binding of names, mutability of objects, a "freeze" protocol) you are looking for? You say:
That seems very odd. That would mean that you can't pass constants to functions, or put them in lists or dicts, since that would create new references to the object. What if an object has already got more than one reference? >>> import gc >>> count = len(gc.get_referrers(None)) >>> print(count) 1771 With more than 1700 references to the None object, I guess we can't create a constant None. That's going to go straight into the list of Python WTFs. Small ints also have many references: >>> len(gc.get_referrers(1)) 65 I think people would be surprised if they can't make a constant 1. I know I would be. -- Steve

Reply to Steve D'Aprano - I am talking about constant name binding. Once the name is bind it cannot be changed. The data will remain immutable or mutable.
Well I thought about constant name binding with freeze protocol but it didn't seem to be Pythonic. So I changed my initial idea to have constant name binding. Now we can create multiple references.

Sorry for the name conflict. I tried to type Steven D'Aprano but instead it resulted in Steve D'Aprano

Great Idea, I have joined the mailing list to write the same idea. As I can't find the great difference between Final and Constant, So, I will use the name Final. I suggest one the following syntax: from collection import Final 》x = Final(100) 》print(x) 》100 》y = x*2 》Print(Y) 》200 》print (type(x)) 》< Final object.int at xxxxx> 》x=0 File "<stdin>", line 1 SyntaxError: can't assign to Final My understanding is Final will prevent x from reassigned. But if x is dict or list or string. it can be mutated in place. 》x = Final([1,2]) 》x.append(3) 》print(x) [1,2,3] If the programmer needs list that can't changed, he should move to other data structure like tuple. By using tuple & Final, the x will not accept reassigning nor mutation.

tabeb qena writes:
The syntaxes proposed already are fine. The problem is motivation. Most of us don't think it's a great idea, and the claimed benefits that are of general interest, such as potential optimizations, turn out to be hard to make concrete. Your mission, should you choose to accept it, is to come up with use cases and benefits that are persuasive to more developers, and especially to the core developers. This post will self-destruct in 10, 9, 8, .... :-) Steve

Greetings, Just a light-hearted note, if ever the idea is taken seriously, variable: constant = 10 seems more pythonic to me. constant variable = 10 opens the doors for int x = 5 etc Kind Regards, Abdur-Rahmaan Janhangeer about <https://compileralchemy.github.io/> | blog <https://www.pythonkitchen.com> github <https://github.com/Abdur-RahmaanJ> Mauritius

typing.Final actually means something like "cannot be reassigned", whereas constant variable means "cannot change". Consider e.g. class Spam: def __init__(self): self.eggs = 0 @final # method cannot be overridden (which is more related to "reassignment" than to "change") def more(self): self.eggs += 1 spam: Final[Spam] = Spam() spam.more() # This is allowed, but spam changed del spam # Allowed as well Moreover, `Final` is part of typing, which is strange because it indicates a property of the variable name itself, not of its type. Perhaps the constant keyword can become a replacement for the confusing `typing.Final`. So "constant" is semantically different than `typing.Final` (and `typing.final`), and it makes more sense to have it be a keyword (e.g. `constant spam`), instead of it being an annotation; it only should be used when declaring variables and attributes (e.g. `def f(a: Final)` is not allowed).

On Tue, May 25, 2021 at 7:30 AM Joren <jhammudoglu@gmail.com> wrote:
What's the definition of "cannot change"? Which of these counts as a change? x = (42, ["spam"]) x[1][0] = "ham" # This? lst = ["spam"] y = (42, lst) lst[0] = "ham" # This? r = random.Random() r.randrange(10) # This? class C: pass class D(C): pass # Is this changing X? x is a tuple, and we already know that they're immutable. Yet its value changed when something else changed. In y's case, the assignment never even mentions the tuple, yet y's value still changes. The Random instance has internal state which changes every time you ask for a random number. And you can ask a class for all of its subclasses, so the detectable behaviour of it changes when you add a new subclass. Requiring that a name not be rebound is well-defined and testable. Requiring that an object not change is either trivial (in the case of, say, an integer) or virtually impossible (in the case of most objects). What would be the advantage of such a declaration? ChrisA

We could define "change" in terms of the hash of the object the name points to, as well as the name itself (the pointer to the object).

On Tue, May 25, 2021 at 8:09 AM Joren <jhammudoglu@gmail.com> wrote:
We could define "change" in terms of the hash of the object the name points to, as well as the name itself (the pointer to the object).
The hash of a random.Random() object doesn't change when its state does (its derived solely from its id). Nor does the hash of a class. Nor an instance of a class defined simply as "class Thing: pass". ChrisA

On Mon, May 24, 2021 at 5:43 PM Chris Angelico <rosuav@gmail.com> wrote:
What would be the advantage of such a declaration?
ChrisA
## Existing threads re: consts and applications thereof So, `/? from:me pyrsistent` I found a few results: - "[Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)" 2016-04 https://mail.python.org/pipermail/python-dev/2016-April/143958.html - ~Sandboxing python within python is nontrivial to impossible; consts might help a bit - https://mail.python.org/pipermail/python-dev/2016-April/143958.html - "Proposal to add const-ness type hints to PEP-484" https://mail.python.org/archives/list/python-ideas@python.org/thread/OVPF5I6... - https://github.com/python/typing/issues/242 - "Final names and attributes" https://github.com/python/mypy/pull/5522 This is where `typing.Final` comes from. - "[Python-ideas] "Immutable Builder" Pattern and Operator" https://mail.python.org/pipermail/python-ideas/2017-January/044374.html - [pyrsistent] and "fn.py [do] immutables: https://github.com/kachayev/fn.py/blob/master/README.rst#persistent-data-str... " - "[Python-ideas] Add recordlcass to collections module" https://groups.google.com/g/python-ideas/c/9crHfcCBgYs/m/6_EEaWJAAgAJ - ORMs (e.g. Django, SQLAlchemy) require "dirty state" checking to know which object attributes have changed and need an SQL statement to be executed to synchronize the state; this is relevant because when we're asking for mutable namedtuple we're often trying to do exactly this pattern. - "[Python-ideas] Suggestions: dict.flow_update and dict.__add__" https://www.google.com/search?q=%22%5BPython-ideas%5D+Suggestions%3A+dict.fl... precedes dataclasses. pyrsistent also has 'freeze' and 'thaw' functions for immutability. PRecord extends PMap, which implements __add__ as self.update(arg) (which does not mutate self) https://github.com/tobgu/pyrsistent/blob/master/README.rst#precord
https://github.com/tobgu/pyrsistent/blob/master/pyrsistent/_pmap.py
PyArrow Plasma object ids, "sealing" makes an object immutable,
- "[Python-ideas] How to prevent shared memory from being corrupted ?" https://www.google.com/search?q=%22How+to+prevent+shared+memory+from+being+c... pyristent
https://arrow.apache.org/docs/python/plasma.html#creating-an-object-buffer
- [Python-ideas] Experimenting with dict performance, and an immutable dict https://mail.python.org/archives/list/python-ideas@python.org/message/DNBGUJ... throughout its lifetime and need not worry that somewhere five stack levels below you in the darkest corner of your application someone has decided to remove that element that you expected to be there.
What would be the advantage of such a declaration?
Constants don't need to be locked or unlocked; which is advantageous for parallelism and reasoning about program correctness. True consts (wherein everything referred to in that object is 'frozen' and immutable or at least only modifiable with e.g. copy-on-write) wouldn't require locks, which would be post-GIL advantageous. You could do consts by never releasing a threading.Lock (or similar): - https://docs.python.org/3/library/asyncio-sync.html#locks - https://docs.python.org/3/library/threading.html#lock-objects - This from https://docs.python.org/2/library/sets.html?highlight=immutable#immutable-tr... re ImmutableSet/FrozenSet is not present in the python 3 docs: https://docs.python.org/3/library/stdtypes.html#set-types-set-frozenset Though - even if Python enforced normal consts in the language - all of the other code objects would still be mutable, so you still have the impossibility of sandboxing python. Functional and contracts coding styles rely upon invariance; which can be accomplished with various third-party packages that enforce const-ness throughout what may be an object tree behind that reference that would otherwise need to be copy.deepcopy()'d. ## pyrsistent Src: https://github.com/tobgu/pyrsistent
collections and pyrsistent collections. > - Flexible transformations of arbitrarily complex structures built from PMaps and PVectors.
## icontract Src: https://github.com/Parquery/icontract
https://en.wikipedia.org/wiki/Design_by_contract https://en.wikipedia.org/wiki/Invariant_(mathematics)#Invariants_in_computer... [ https://en.wikipedia.org/wiki/Class_invariant ] What is the difference between "invariant" and "constant" and "final"?

On Fri, Jun 18, 2021 at 12:43 AM Wes Turner <wes.turner@gmail.com> wrote:
That only works if you have a garbage collector that doesn't depend on reference counts (as CPython's does). Otherwise, you still need to modify the object, in a trivial sense, every time a reference is added or removed. ChrisA

On Thu, Jun 17, 2021 at 10:50 AM Chris Angelico <rosuav@gmail.com> wrote: > On Fri, Jun 18, 2021 at 12:43 AM Wes Turner <wes.turner@gmail.com> wrote: > > > > > What would be the advantage of such a declaration? > > > > Constants don't need to be locked or unlocked; which is advantageous for > parallelism and reasoning about program correctness. > > True consts (wherein everything referred to in that object is 'frozen' > and immutable or at least only modifiable with e.g. copy-on-write) > > wouldn't require locks, > > which would be post-GIL advantageous. > > > > That only works if you have a garbage collector that doesn't depend on > reference counts (as CPython's does). Otherwise, you still need to > modify the object, in a trivial sense, every time a reference is added > or removed. > - https://pythoncapi.readthedocs.io/gilectomy.html > Gilectomy is Larry Hastings’s project to attempt to remove the GIL from CPython. It a fork on CPython which uses lock per object rather than using a Global Interpreter Lock (GIL). - https://lwn.net/Articles/754577/ Update re: Gilectomy - There's probably a doc somewhere listing all of the post-GIL works? (Consts could be a helpful performance optimization for like all of the approaches I've seen) - https://lwn.net/Articles/754162/ Subinterpreters PEP > The PEP provides for a shared-nothing concurrency model. It has a minimal Python API in an interpreters module. It also adds channels to pass immutable objects between interpreters. A subinterpreter will retain its state, so the interpreter can be "primed" with modules and other setup in advance of its use. https://www.python.org/dev/peps/pep-0554/#a-disclaimer-about-the-gil https://distributed.dask.org/en/latest/memory.html#clearing-data > > ChrisA > _______________________________________________ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-leave@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/BZ5WQZP5BSJEO3FY2H4DK4RLDHZBOO3M/ > Code of Conduct: http://python.org/psf/codeofconduct/ >

"Constant variables" is a contradiction in terms. If it is constant, it cannot be a variable, and vice versa. Can we be more precise in the language used please? We have two independent concepts here: * name bindings: names can be bound to a value, or unbound with the `del` statement; * values can be mutable or immutable. "Constant" might refer to immutability. `1` is a constant, but `[]` is not, because the list can be mutated. In some languages (not Python), we can "freeze" a mutable object and turn it immutable. Or it might refer to bindings: a perhaps a constant name cannot be unbound or rebound to a new object, but the object may be either mutable or immutable. Can you explain what combination of these three features (binding of names, mutability of objects, a "freeze" protocol) you are looking for? You say:
That seems very odd. That would mean that you can't pass constants to functions, or put them in lists or dicts, since that would create new references to the object. What if an object has already got more than one reference? >>> import gc >>> count = len(gc.get_referrers(None)) >>> print(count) 1771 With more than 1700 references to the None object, I guess we can't create a constant None. That's going to go straight into the list of Python WTFs. Small ints also have many references: >>> len(gc.get_referrers(1)) 65 I think people would be surprised if they can't make a constant 1. I know I would be. -- Steve

Reply to Steve D'Aprano - I am talking about constant name binding. Once the name is bind it cannot be changed. The data will remain immutable or mutable.
Well I thought about constant name binding with freeze protocol but it didn't seem to be Pythonic. So I changed my initial idea to have constant name binding. Now we can create multiple references.

Sorry for the name conflict. I tried to type Steven D'Aprano but instead it resulted in Steve D'Aprano

Great Idea, I have joined the mailing list to write the same idea. As I can't find the great difference between Final and Constant, So, I will use the name Final. I suggest one the following syntax: from collection import Final 》x = Final(100) 》print(x) 》100 》y = x*2 》Print(Y) 》200 》print (type(x)) 》< Final object.int at xxxxx> 》x=0 File "<stdin>", line 1 SyntaxError: can't assign to Final My understanding is Final will prevent x from reassigned. But if x is dict or list or string. it can be mutated in place. 》x = Final([1,2]) 》x.append(3) 》print(x) [1,2,3] If the programmer needs list that can't changed, he should move to other data structure like tuple. By using tuple & Final, the x will not accept reassigning nor mutation.

tabeb qena writes:
The syntaxes proposed already are fine. The problem is motivation. Most of us don't think it's a great idea, and the claimed benefits that are of general interest, such as potential optimizations, turn out to be hard to make concrete. Your mission, should you choose to accept it, is to come up with use cases and benefits that are persuasive to more developers, and especially to the core developers. This post will self-destruct in 10, 9, 8, .... :-) Steve
participants (10)
-
Abdur-Rahmaan Janhangeer
-
Chris Angelico
-
Joren
-
Shreyan Avigyan
-
Stephen J. Turnbull
-
Stestagg
-
Steven D'Aprano
-
tabeb qena
-
Thomas Grainger
-
Wes Turner