Const in python?

[Alex Martelli]

David Brown wrote:
   ...
> 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 -

And what if you want to find out how many times operator + is used (on
any objects whatsoever, just as here you want to count uses of built-in
'len' on any object whatsoever)?  What makes counting the uses of 'len'
more important than counting the uses of '+', enough to warrant slowing
all programs down (or making everything more complicated) to enable the
former by simpler means than the latter?

I think it would be quite acceptable to say that for either of these
tasks you need to instrument the bytecode, intercepting the 'operators'
of your interest (with at least some built-ins counting as operators).
Further, I'd LOVE it if the compiler was able to optimize the specific
use "for i in range(len(X)):", even if that were to interfere with the
ability to count usages of len and/or range;-).

> 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?

In general, I entirely agree that the ability to explicitly change and
restore the locking would also be desirable.  But if overriding of
built-ins needs to be usable, there must also be a compilation mode 
that inhibits the optimizations of built-ins into new dedicated opcodes
(or other related optimization strategies).  Whether the marginal gains
are worth the extra work, I dunno -- perhaps, if the extra work isn't
all that much...


Alex