Const in python?

[Alex Martelli]

David Brown wrote:

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

Not for ALL types of objects -- no way to get at the + used when you
code 2+2.  You can override __plus__ in your OWN type -- just as you
can override __len__ in your own type.  That you can REBIND the built-in
name 'len' is a completely different issue, and you cannot do anything
comparable with '+' (you need to work on bytecode, etc, etc).

> 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

"When needed" is the key here.

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

Yes, that would make sense.  But to enable compiler optimizations,
unlockable builtins would not be an option.

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

It may be necessary to allow disabling of the locked-builtins optimization,
perhaps.  But I suspect the amount of work to allow both ways would not
necessarily be trivial.


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

It does?  Didn't last I checked it, but that WAS quite a while ago.


Alex