Does Python need "const" ? (Re: PEP 218 Re: ANN: set-0.1 module available)

[Huaiyu Zhu]

Erik Max Francis <max at alcyone.com> wrote:
>"James J. Besemer" wrote:
>
>> Python has clear precedent for doing so, in that strings, tuples
>> and long integers all are immutable.
>
>Why is that a precedent?  Lists aren't immutable, and you're as likely
>to want to add and remove objects from a set as you are to modify a
>list.

Maybe Python needs a keyword "const".

I've been toying with this idea for quite some time.  It is my observation
that a substantial proportion of the discussions about Python design touches
on the issue of mutability:

- Is this thing hashable?
- Should I compare with contents or with object id?
- What does += do?  Why is it different for list and numbers?
- Can I use string as a buffer?
- Some of the great uses of __getattr__  and __setattr__.
- Some security discussions.
- Why don't Python have a machine code compiler?
- How do I codify the idea that this thing will not change here?
- Speed and garbage collection for tuples (on python-dev).

There are more but I can only remember these right now.

Python provides immutable types for some objects (numbers, strings) and
mutable types for others (dictionaries, functions, classes, modules) and
both versions for some (tuples and lists).

In real life we have to deal with some versions of objects that cannot
change, and some versions that can, for any kind of objects.  It might be
better to separate out the mutability aspect of objects from other aspects,
and maybe even allow objects to change the mutability under some rules.

There are at least two kinds of possible meaning of 'const' in Python: const
reference and const object.

To illustrate the idea, I'll give some examples, assuming that all things
are mutable a priori without the 'const' keyword, which is not true today.
Suppose we use prefix 'const' to refer to names and postfix 'const' to refer
to objects, we could say

# const reference to mutable object
const a = "abc"
#   forbids a = "xyz"
#   allows b = a; a += "uvw"; which would set b to "abcuvw".

# mutable reference to const object
a = "abcd" const
#   forbids a[2] = 'g'
#   allows a = 42

# const reference to const object
const a = "abc" const
#   forbids both rebinding a to another object and changing the current
#   object. 

# more examples
a = [1, 2, 3] const    # equivalent to today's a = (1, 2, 3)
a = "abc" const        # equivalent to today's a = "abc"
a = {1, 2, 3} const    # a set that can be hashed by content
const a = {1, 2, 3}    # a set that should be hashed by id (like a container)
def f(x const)         # will not modify x object inside f.
class A:
   def meth1(self, x)  # may modify self and x
   def meth2(self const, x)   # may not modify an members, but may modify x
   def meth3(self, x const)   # may modify members of self.

These ideas are not a concrete proposal at the moment.  What I'm hoping for
is that perhaps by seeing a connection among these issues a more coherent
proposal might emerge that is better than incremental changes.  The issue of
implementation and compatibility is not on my radar screen yet.

Fire up your ideas.

Huaiyu