Python 2.4: Why only assignments to None are forbiden?

[Bengt Richter]

On Sat, 13 Nov 2004 08:04:28 -0600, "John Roth" <newsgroups at jhrothjr.com> wrote:

>
>"Josef Meile" <jmeile at hotmail.com> wrote in message 
>news:4195190f at pfaff2.ethz.ch...
>> Hi,
>>
>> Textually from the highlights of python 2.4:
>>
>> "Assigning to None - the compiler now treats assigning to None as a 
>> SyntaxError."
>>
>> I think in general assignments to built-in types, functions, and variables 
>> should be also forbiden.
>
>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:

 >>> def calledat(level=2): # default = caller's caller
 ...     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 '???'
 ...
 >>> def showlencall(seq):
 ...     print '---> len(%r) from %s'%(seq, calledat(2))
 ...
 >>> __builtins__.len
 <built-in function len>
 >>> def showlencall(seq):
 ...     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??

 >>> len = showlencall
 >>> def foo(x):
 ...     return len(x)
 ...
 >>> foo(range(4))
 ---> 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