Home Original page

One Python 2.1 idea

Alex Martelli aleaxit at yahoo.com
Mon Dec 25 18:54:09 EST 2000 
"Tim Peters" <tim.one at home.com> wrote in message
news:mailman.977771949.17911.python-list at python.org...
    [snip]
> > Can the code for list comprehensions be made faster?
>
> Sure.  "bang for the buck" is limited by how often a particular trigger is
> pulled, though, and listcomps are currently barely used.  This isn't a
> technical problem, it's a problem of finding someone motivated enough to
> bother doing something about it.  You're not -- and neither am I.

I might be, given that I think list comprehensions *deserve* wider
usage and I'd be loath to think of people who *might* use them...
and won't because of a silly 5%-performance-issue (I guess I might
'think of it as evolution in action', but, I'm a softy!-).

If I'm right that the issue is allocation, then I'd need a different
opcode at the start (a build-list variation) and one at the end to
say 'ok, listbuilding done now, please ensure it's a normal list
without too much extra fat'; the former would change the append
method pointer of the list object to {either reallocate exponentially,
or, probably better, build the list in disjoint pieces -- as nothing
BUT 'append' will be used on the list until ok-done-now time},
the latter would (if needed) recompact it up and restore the normal
append method for possible future uses.

Am I wildly off-base...?  If not, it seems to me that procuring
an acceptable diff-program is going to be the largest part of
making a patch to submit...:-).


Alex
More information about the Python-list mailing list