Mailing List Archive

[/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.
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.

> (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?

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.

Has anyone else seen a leak?

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/

"M.-A. Lemburg" wrote:
>
> > > (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.

Using the Unicode patched CVS version there's no leak anymore.
Couldn't find a 1.5.2 version on my machine... I'll build one
later.

--
Marc-Andre Lemburg
______________________________________________________________________
Business: http://www.lemburg.com/
Python Pages: http://www.lemburg.com/python/

Guido van Rossum wrote:
>
> ..
> Multi-arg
> append probably won't be the only reason why e.g. Digital Creations
> may need to release an update to Zope for Python 1.6. Zope comes with
> its own version of Python anyway, so they have control over when they
> make the switch.

My concernc is when I want to build an application with a module that
only works with Python 1.5.2 and another one that only works with Python
1.6. If we can avoid that situation by making 1.6 compatible with 1.5.2.
we should. By the time 1.7 comes around I will accept that everyone has
had enough time to update their modules. Remember that many module
authors are just part time volunteers. They may only use Python every
few months when they get a spare weekend!

I really hope that Andrew is wrong when he predicts that there may be
lots of different places where Python 1.6 breaks code! I'm in favor of
being a total jerk when it comes to Py3K but Python has been pretty
conservative thus far.

Could someone remind in one sentence what the downside is for treating
this as a warning condition as Java does with its deprecated features?
Then the CP4E people don't get into bad habits and those same CP4E
people trying to use older modules don't run into frustrating runtime
errors. Do it for the CP4E people! (how's that for rhetoric)
--
Paul Prescod - ISOGEN Consulting Engineer speaking for himself
"We still do not know why mathematics is true and whether it is
certain. But we know what we do not know in an immeasurably richer way
than we did. And learning this has been a remarkable achievement,
among the greatest and least known of the modern era."
- from "Advent of the Algorithm" David Berlinski
http://www.opengroup.com/mabooks/015/0151003386.shtml

Just noting that two instances of this were found in Zope.

[/F]
> append = list.append
> for x in something:
> append(...)

[Tim]
> 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.

[Paul Prescod]
> ...
> Could someone remind in one sentence what the downside is for treating
> this as a warning condition as Java does with its deprecated features?

Simply the lack of anything to build on: Python has no sort of runtime
warning system now, and nobody has volunteered to create one. If you do
<wink>, remember that stdout & stderr may go to the bit bucket in a GUI app.

The bit about dropping the "L" suffix on longs seems unwarnable-about in any
case (short of warning every time anyone uses long()).

remember-that-you-asked-for-the-problems-not-for-solutions<wink>-ly y'rs
- tim