[Python-3000] Python 3000 Status Update (Long!)

[Mike Klaas]

On 22-Jun-07, at 2:44 PM, Jean-Paul Calderone wrote:

> On Fri, 22 Jun 2007 14:28:12 -0700, Alex Martelli  
> <aleaxit at gmail.com> wrote:
>
> Could be.  I don't find many of my programs to be bottlenecked on
> compilation time or import time, so these optimizations look like
> pure lose to me.

Nor do mine, though this complaint is common (python startup time in  
general, esp for short scripts).

>> However, this would not afford the same level of optimization (e.g.
>> special opcodes for very lightweight builtins such as len), and if it
>> involved making all dicts richer to support 'observers on key  
>> rebinds'
>> might possibly slow dicts by enough to more than counteract the
>> benefits (of course it might be possible to get away with replacing
>> builtin and modules' dicts with instances of an "observabledict"
>> subclass -- possibly worthwhile, but a HUGE workload to undertake in
>> order to let some weirdo reassign 'len' in builtins at random times).
>> Practicality beats purity.
>>
>
> I also don't find much of my code bottlenecked on local name lookup.
> Function call and attribute lookup overhead is a much bigger killer,
> but I can still write apps where the Python VM isn't the bottleneck
> without really trying, and when something is slow, giving attention
> to the miniscule fraction of my overall codebase which causes the
> problem is itself not much of a problem.
>
> Is it neat when CPython gets faster overall?  Sure.  Is it worth
> complications to the language for what is ultimately a tiny
> speedup?  Not on my balance sheet.

I agree that making CPython .5% faster is not compelling, but there  
is value in knowing that certain patterns of code are optimized in  
certain ways, so that less mental effort and tweaking is necessary in  
those bottleneck functions.  Further, it allows the code to remain  
clearer and truer to the original intent (rebinding globals to locals  
is _ugly_).

It is like constant folding: I don't expect that it produces much by  
way of general CPython speedup, but it allows clearer code to be  
written without micro-worries about micro-optimization.

s = 0
for x in xrange(10):
       s += 10*1024*1024 # add ten MB

I _like_ being able to write that, knowing that my preferred way of  
writing the code is not costing me anything.  It would, of course, be  
even better if the whole loop disappeared :)

-Mike