[Python-Dev] breaking list.append()

[M.-A. Lemburg]

Tim Peters wrote:
> 
> [/F]
> >     append = list.append
> >     for x in something:
> >         append(...)
> 
> [M.-A. Lemburg]
> > Same here.  checkappend.py doesn't find these
> 
> As detailed in a c.l.py posting, I have yet to find a single instance of
> this actually called with multiple arguments.  Pointing out that it's
> *possible* isn't the same as demonstrating it's an actual problem.  I'm
> quite willing to believe that it is, but haven't yet seen evidence of it.

Haven't had time to check this yet, but I'm pretty sure
there are some instances of this idiom in my code. Note that
I did in fact code like this on purpose: it saves a tuple
construction for every append, which can make a difference
in tight loops...

> For whatever reason, people seem much (and, in my experience so far,
> infinitely <wink>) more prone to make the
> 
>     list.append(1, 2, 3)
> 
> error than the
> 
>     maybethisisanappend(1, 2, 3)
> 
> error.

Of course... still there are hidden instances of the problem
which are yet to be revealed. For my own code the siutation
is even worse, since I sometimes did:

add = list.append
for x in y:
   add(x,1,2)

> > (a great tool BTW, thanks Tim; I noticed that it leaks memory badly
> > though).
> 
> Which Python?  Which OS?  How do you know?  What were you running it over?

That's Python 1.5 on Linux2. I let the script run over
a large lib directory and my projects directory. In the
projects directory the script consumed as much as 240MB
of process size.
 
> Using 1.5.2 under Win95, according to wintop, & over the whole CVS tree, the
> total (code + data) virtual memory allocated to it peaked at about 2Mb a few
> seconds into the run, and actually decreased as time went on.  So, akin to
> the bound method multi-argument append problem, the "checkappend leak
> problem" is something I simply have no reason to believe <wink>.  Check your
> claim again?  checkappend.py itself obviously creates no cycles or holds on
> to any state across files, so if you're seeing a leak it must be a bug in
> some other part of the version of Python + std libraries you're using.
> Maybe a new 1.6 bug?  Something you did while adding Unicode?  Etc.  Tell us
> what you were running.

I'll try the same thing again using Python1.5.2 and the CVS version.
 
-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/