Const in python?

[David Brown]

"Alex Martelli" <aleax at aleax.it> wrote in message
news:MdWfa.5793$Jg1.132033 at news1.tin.it...
> 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
>

You are right - constants or locked dictionaries could make a huge
difference to optomisations.  Most of my work involves embedded systems
programming rather than Python programming, so I know about the sort of
difference it can make (optomisations are often more important with small,
limited microcontrollers).

There is always a balance to be struck between speeding things up for the
vast majority of uses, while not breaking functionality that a few programs
might use.  For example, some programs might want to change some built-ins,
or some common library functions - perhaps as part of debugging or profiling
(maybe you want to find out how many times "len" is called - overriding the
built-in with a wrapper function lets you run the rest of the code
unmodified).  So if there is a locking mechanism, it must be possible to get
around it - perhaps it should be possible to manually unlock the dictionary,
make a change, and then lock it again?