How do you create constants?

[Alex Martelli]

"Rainer Deyke" <root at rainerdeyke.com> wrote in message
news:g%lL5.138552$g6.65232584 at news2.rdc2.tx.home.com...
    [snip]
> 1. The usage "const x = ..." means that the __dict__ is made partially
> immutable.  This is possible, but probably more trouble than it's worth.
>
> 2. It is not obvious wether const-ness applies to objects or references.
I
> vote for the latter.

It seems you mean 'the object referred to cannot be changed through
this reference', rather than 'this reference cannot be changed' (else,
if each reference carried the information about whether it's mutable,
where's the "more trouble" in making specific entries in a dictionary
(which are also references, after all) carry that same information?).

But *that* does seem troublesome indeed.  The general case is something
like
    areference.amethod(some,args)
although some specific subcases may have alternate syntax sugar,
e.g. if 'amethod' is actually '__setitem__' this could be equivalently
written
    areference[some]=args
which is what you exemplify below.  Now, how do we tell the object
referred to by 'areference' that it's not supposed to effect any
changes this time?  Note that catching/inhibiting changes to that
object's __dict__ is surely not enough -- the implementation of
__setitem__ could well be, say:
    def __setitem__(self, index, value):
        globalblob[index]=value

If the reference itself carries the constness-bit, then 'self',
here, is not carrying it, is it?  It's the same _reference_ as
when the same method is called on the same object through another
different reference.

Even if it were, there would have to be an explicit test by the
method author to honor the 'constness'.  Or we would have to
mark methods to denote 'constness' ("this method cannot be
called on a constant reference", "this is the version to call
if the reference is constant", ...), and even then it's still
basically down to the code author -- just like 'const' in C,
which is _supposed_ to denote 'logical constness' but clearly
can't (so it tries to ensure physical constness instead, not
normally the key issue -- btw, let's remember to add a 'mutable'
attribute, as in C++, to members, to indicate "this attribute
can be physically changed without impairing logical constness",
as well as having to rely on coders' judgment anyway to respect
the 'logical constness' constraint...).

In short, the design trouble that follows from wanting to
enable the following (not as a hacked up magic special case,
but with the generality and simplicity that is Python's
hallmark):

> a = [1, 2, 3]
> b = const a
> a[0] = 5
> print b # --> '[5, 2, 3]'
> b[0] = 1 # Raises ConstError

...appears to entail a lot of work for little real gain.


Me, I'd happily settle for a couple of state-bits on
dictionaries -- whether to allow rebinding of existing
entries, whether to allow creation of new entries.  This
has modest usefulness (and, if one had to choose, the
alternative of being able to use general mapping objects
wherever dictionaries are currently allowed would no
doubt be more general -- allowing this tweak as well as
others, such as user-mappings with per-key 'constness',
and others yet not related to constness as well), but
it seems to me it could be implemented easily, with clean
and unsurprising semantics, and no serious performance
implications...


Alex