Const in python?

[Alex Martelli]

David Brown wrote:
   ...
> notify you of some silly mistakes, but in Python, the run-time typing and
> binding means that you can make so many silly mistakes (it's the price you
> pay for the power and flexibility) that assigning to constants is a minor
> issue.

Yes, but it WOULD be nice to be able to "lock dictionaries" (in various
meanings of the term) -- it would help catch more errors sooner.  The BDFL
mentioned he'd like that, if somebody offered a patch, for one specific
reason: he's considering a future language change to disallow changing
certain module attributes from outside the module, in order to enable
some major future optimizations; being able to selectively "lock" some
parts of a module's dictionary, so attempts to modify them could give
warnings or exceptions, would be a first step.  As for me, the ability to
selectively lock some dictionaries is one I desired ever since I first met 
Python, and proposed it in one of my earliest posts here (admittedly I
never cared enough to actually go and make a patch...;-).

Let me try to explain the optimization issue a bit better.  Say that
in a module I have an occurrence of len(x) -- the compiler can see
that len must be a global or builtin.  Right now, the compiler can
still do nothing except generate a name lookup for len then a call
to it with x as an argument.  But IF it could be forbidden for any
OTHER module to bind in THIS module the names of builtins... then the
compiler could see if this module's own code can ever rebind global
name 'len' (or contains constructs that might rebind anything, such
as exec in global scope of 'from blah import *'), and then it might
still generate the same code as today; but more often than not the
compiler might see that len MUST refer to the built-in and "inline"
it.  This might be a substantial speed boost for some kinds of uses
of built-ins.  It would also make it substantially easier to reason
about programs, both on human and automatic levels -- right now,
when I see:

for i in range(len(x)):
    bleeb(x[i], x[i/2])

I of course ASSUME this means the BUILT-IN len and range -- and thus 
that this code is processing all of x's items.  But I don't really
KNOW, and if some silly code is trying to do black magic on this
module from the outside and slightly changing range or len the bugs
that result might be quite hard to find, as the assumption is strong.

There is no real benefit in ALLOWING such "overriding of builtins"
which is just about never uses, and it inhibits optimizations as
well as "potentially" making programs hard to reason about.


The one issue I can see is how to effect locking WITHOUT measurable
costs for the normal case in which a given key is not locked.  The
workings of dictionaries are so crucial to Python's speed, that it
would be all too easy to slow everything down measurably.  But I
guess the right way is first to make a little patch and then check
what happens to performance, before vs after.  Hmmm...


Alex