Const in python?

[David Brown]

"Alex Martelli" <aleax at aleax.it> wrote in message
news:bAXfa.6199$Jg1.139809 at news1.tin.it...
> 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?
>

Is it not possible to override the "+" operator as well?  As you point out,
the vast majority of users have no need of doing that sort of thing - that
includes me, so I've never looked at how it might be done.  My preference
is, of course, to have the best of both worlds - in general I too would
prefer increased speed for common operations, but I think the flexibility to
override things when needed is important.  In the case of something like
"len", or "+", the overwhelming majority of uses do not require overriding,
and could benifit from speed-ups.  But what about, for example, methods in a
user defined class?  The majority of these are static, but sometimes you
want to change them - the ability to do this, even while running the
program, is one of the big benifits of Python.  If it were practical, then
flexible locking would allow you to choose - perhaps builtins and standard
libraries would be locked by default, but unlockable if desired, and other
modules would be unlocked until explicitly locked.

Failing that, a compiler (command-line) switch that selects locked or
unlocked builtins (with locked being the default) would be likely to make a
big difference, with perhaps less work.

Perhaps it would also be possible to make use of a pysco-like system, except
that optomised Python bytecode is produced rather than machine code?  As far
as I understand it, pysco "locks" common functions such as built-ins.

David


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