As Ian points out in another response, there's been some
discussion about making a fairly large subset of the builtins
name space immutable, and also to disallow shadowing
of builtins with identical names in module scope.
The main reason for this is performance optimization.
Right now, the len() function, for example, requires
a lookup and two (!) function evaluations. If the
compiler could trust that len() was always the function
in the builtins, then it could compile a direct call to the
__len__() function on the object, at a savings of the
lookup and one function call. There is a considerable savings
projected over the entire name builtin name space.
There's always a tension between protecting people
against common errors and keeping the language
as flexible and dynamic as possible. I'd prefer that
the editors and IDEs take up the slack. For example,
I found that JEdit colorized builtins differently from
ordinary names. This pointed out a few bad habits
I'd fallen into, without taking away the option of
overriding something when I really wanted it.
In any case, it won't happen in 2.4.x. That kind
of change will wait for a full point release: 2.5
or later.
John Roth
I don't mind things being locked or unlocked by sensible
default if I have a key. I.e., I'd like some way of telling
the compiler to generate current-style lookup code for a particular
builtin that might be optimized in the future.
Since this is a compile-time issue , perhaps it is time to consider
a pragma statement as a framework for telling python pre-runtime things
like optimization info? E.g., pragma could send in-context meta-info
to various python infrastructure components using python method call syntax
which the compiler could recognize in the token stream and compile and
execute in its working environment right then. So e.g.,
pragma compiler.override(len=True, cmp=False)
would say "after this statement in the token stream, generate code for
old-style lookup of len (allowing overriding) and cease to do that for cmp."
Right now we can do this:
... f = sys._getframe()
... for _ in xrange(level): f = f and f.f_back
... return f and '%s line %s'%(f.f_code.co_name, f.f_lineno) or '???'
... ... print '---> len(%r) from %s'%(seq, calledat(2))
... ... print '---> len(%r) from %s'%(seq, calledat(2))
... return __builtins__.len(seq)
...
Here (or at the top of this scope) we would in the future need:
pragma compiler.override(len=True) # be able to specify scope other than local??
... return len(x)
... ---> len([0, 1, 2, 3]) from foo line 2
4
Not that this shows implicit calls to __len__ in various places...
Hm, that might make an interesting pragma
pragma compiler.methodhook(__len__= my_len_tracer)
I better stop here ;-)
Regards,
Bengt Richter