Home Original page

Const in python?

David Brown david at no.westcontrol.spam.com
Tue Mar 25 10:57:42 EST 2003 
"Alex Martelli" <aleax at aleax.it> wrote in message
news:jL_fa.7564$Jg1.161396 at news1.tin.it...
> 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.

I'm not sure, but I think that it assumes that methods and functions are not
changed within functions.  Perhaps it generates seperate copies of the
function when you rebind functions or methods, like it does if you call
functions or methods using different types.  I'm on wobbly ground here,
having read a bit about psyco but not really dug into the details, but it
did strike me that there was maybe something to gain here.  Compiling to
optomised byte code is obviously not going to get as big a performance gain
as compiling to machine code, but maybe it could get somewhere in between.

>
>
> Alex
>
More information about the Python-list mailing list