Mailing List Archive

MAL wrote:
> Not sure about remove(), index() and count(), but the change
> to .append() will break *lots* of code !

ouch. missed this checkin. I thought all the append fixes
in the standard library were made to make it clearer that
this use was deprecated.

some random grepping through our code repositories makes
me think this should be left for Py3K.

</F>

> > *** INCOMPATIBLE CHANGE: This changes append(), remove(), index(), and
> > *** count() to require exactly one argument -- previously, multiple
> > *** arguments were silently assumed to be a tuple.
>
> Not sure about remove(), index() and count(), but the change
> to .append() will break *lots* of code !

Agreed. But 1.6 is as good a point to break it as any -- what's the
point in putting this off? This isn't big enough to wait for 2.0. I
could've done it in the 1.5.x series, but decided not to.

--Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum wrote:
>
> > > *** INCOMPATIBLE CHANGE: This changes append(), remove(), index(), and
> > > *** count() to require exactly one argument -- previously, multiple
> > > *** arguments were silently assumed to be a tuple.
> >
> > Not sure about remove(), index() and count(), but the change
> > to .append() will break *lots* of code !
>
> Agreed. But 1.6 is as good a point to break it as any -- what's the
> point in putting this off? This isn't big enough to wait for 2.0. I
> could've done it in the 1.5.x series, but decided not to.

Hmm, I'd say it doesn't hurt leaving .append() as it is until
2.0. This small change will cause lots of trouble because it's
hard to find (just like the x = 2L; print x[:-1] thingie, btw)...
even though it's easy to fix.

Note: the CVS cgi.py uses list.append(x,y) too.

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

> > > > *** INCOMPATIBLE CHANGE: This changes append(), remove(), index(), and
> > > > *** count() to require exactly one argument -- previously, multiple
> > > > *** arguments were silently assumed to be a tuple.
> > >
> > > Not sure about remove(), index() and count(), but the change
> > > to .append() will break *lots* of code !
> >
> > Agreed. But 1.6 is as good a point to break it as any -- what's the
> > point in putting this off? This isn't big enough to wait for 2.0. I
> > could've done it in the 1.5.x series, but decided not to.
>
> Hmm, I'd say it doesn't hurt leaving .append() as it is until
> 2.0. This small change will cause lots of trouble because it's
> hard to find (just like the x = 2L; print x[:-1] thingie, btw)...
> even though it's easy to fix.

Sigh. It will be just as hard to fix later... I'd really like to
take a hard line stance on this one. After all the docs are quite
clear.

> Note: the CVS cgi.py uses list.append(x,y) too.

Already fixed in CVS.

--Guido van Rossum (home page: http://www.python.org/~guido/)

> MAL:
> > Hmm, I'd say it doesn't hurt leaving .append() as it is until
> > 2.0.

/F:
> fwiw, I definitely agree. I've spotted too many
> places where this change cause a program to
> silently misbehave, rather than blow up (PIL's
> JPEG plugin is just one example...).

Sigh...

This smells of a too-inclusive except clause... Otherwise the program
should have raised a clear exception. I suggest to fix it rather than
whine...

Am I responsible for everybody else's bad coding style?

If it's not in the docs, where does everybody get the idea that this
is legal? (The few cases in the std library are unlikely to be the
only source; they were in pretty obscure places.)

--Guido van Rossum (home page: http://www.python.org/~guido/)

Fredrik Lundh writes ( about .append(x,y) ):
>I suggest adding an explicit warning in the 1.6 docs,
>and removing it in the first post-1.6 release.

What about adding a command-line switch for enabling warnings, as has
been suggested long ago? The .append() change could then print a
warning in 1.6alphas (and betas?), but still run, and be turned into
an error later.

--
A.M. Kuchling http://starship.python.net/crew/amk/
Well, that's a little thing -- the specification.
-- Guido van Rossum at IPC7

MAL:
> Hmm, I'd say it doesn't hurt leaving .append() as it is until
> 2.0.

fwiw, I definitely agree. I've spotted too many
places where this change cause a program to
silently misbehave, rather than blow up (PIL's
JPEG plugin is just one example...).

I suggest adding an explicit warning in the 1.6 docs,
and removing it in the first post-1.6 release.

appendnanny.py, anyone?

</F>

> Fredrik Lundh writes ( about .append(x,y) ):
> >I suggest adding an explicit warning in the 1.6 docs,
> >and removing it in the first post-1.6 release.
>
> What about adding a command-line switch for enabling warnings, as has
> been suggested long ago? The .append() change could then print a
> warning in 1.6alphas (and betas?), but still run, and be turned into
> an error later.

That's better. I propose that the warnings are normally on, and that
there are flags to turn them off or thrn them into errors.
Alternatively, the default should be warnings == errors, with flags to
turn them into warnings or turn them off. Turning them off by default
seems to defeat the purpose -- only the most zealous will use them.

The warning messages should show a source file and line number and
display the source code line if available, just like in a traceback;
but no traceback info should be printed. Also, a warning should only
be printed once per message/file/lineno combination, per Python
invocation. A dictionary could take care of this.

Anybody care to further specify and then code up such a mechanism?

--Guido van Rossum (home page: http://www.python.org/~guido/)

> Am I responsible for everybody else's bad coding style?
>
> If it's not in the docs, where does everybody get the idea that this
> is legal? (The few cases in the std library are unlikely to be the
> only source; they were in pretty obscure places.)

I think you're responsible for a little bit of the confusion. Most
people read the docs at the beginning to learn the basics, and then
experiment with the interpreter. The fact that it worked is naturally
interpreted by users as meaning that it should work. Very few of
Python's semantics are accidental, so people "believe" the interpreter.

Teaching people when ()'s are necessary in Python and when they're not
is not a trivial task if you're talking to someone who'se never heard
the difference between a parse tree and a pear tree. In my courses I
typically say "()'s are sometimes optional" and leave it at that -- I
expect the students' experience to guide them. That experience will be
interaction-driven, not doc-driven.

max/min() is another example, btw. What's the "right" way? To call
them with N arguments where N > 1, or with a sequence argument? If I
look it up in the doc, I can tell (it's the latter, folks) -- but it
seems arbitrary. After all, the max/min calls/macros typically used in
other languages require 2 arguments, so extending that to N arguments is
conceptually at least as easy as shrinking it to a sequence argument.

--david

Guido van Rossum wrote:
>
> > MAL:
> > > Hmm, I'd say it doesn't hurt leaving .append() as it is until
> > > 2.0.
>
> /F:
> > fwiw, I definitely agree. I've spotted too many
> > places where this change cause a program to
> > silently misbehave, rather than blow up (PIL's
> > JPEG plugin is just one example...).
>
> Sigh...

I think you've got a wrong impression here: this is not so
much a design question, it's a timing problem: two months
are not enough to get all our software ready for 1.6 ...

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

> > Am I responsible for everybody else's bad coding style?
> >
> > If it's not in the docs, where does everybody get the idea that this
> > is legal? (The few cases in the std library are unlikely to be the
> > only source; they were in pretty obscure places.)
>
> I think you're responsible for a little bit of the confusion. Most
> people read the docs at the beginning to learn the basics, and then
> experiment with the interpreter. The fact that it worked is naturally
> interpreted by users as meaning that it should work. Very few of
> Python's semantics are accidental, so people "believe" the interpreter.

It's a fair cop.

> Teaching people when ()'s are necessary in Python and when they're not
> is not a trivial task if you're talking to someone who'se never heard
> the difference between a parse tree and a pear tree. In my courses I
> typically say "()'s are sometimes optional" and leave it at that -- I
> expect the students' experience to guide them. That experience will be
> interaction-driven, not doc-driven.

Yes -- and this is one reason why I want to fix append(). I should've
fixed it years ago.

> max/min() is another example, btw. What's the "right" way? To call
> them with N arguments where N > 1, or with a sequence argument? If I
> look it up in the doc, I can tell (it's the latter, folks) -- but it
> seems arbitrary. After all, the max/min calls/macros typically used in
> other languages require 2 arguments, so extending that to N arguments is
> conceptually at least as easy as shrinking it to a sequence argument.

This is different. Maybe the docs are wrong; I always intended for
both max(a, b, ...) and max(seq) to be valid.

(BTW, perhaps the __contains__ changes should be extended to __max__
and __min__? They share many of the same issues.)

--Guido van Rossum (home page: http://www.python.org/~guido/)

On Mon, 28 Feb 2000, Guido van Rossum wrote:
>
> This is different. Maybe the docs are wrong; I always intended for
> both max(a, b, ...) and max(seq) to be valid.

I suppose in this case it's clear what you mean just from the
number of arguments. But there is a potential surprise if someone
who expects to have to say max(a, b, ...) then writes

apply(max, tuple)

and tuple turns out to only have one element. (I don't think
i've ever realized that we could use min() or max() on a sequence.)

> (BTW, perhaps the __contains__ changes should be extended to __max__
> and __min__? They share many of the same issues.)

Indeed -- but then who do you trust? The first element of the
sequence? Is it acceptable for

max(a, b, c, d)

to read as

"a, please tell me which is the maximum among yourself, b, c, and d"

? Does 'a' then have to take care of the type-comparison logic
for consistency with everything else? What if 'a' happens to be
a built-in type but 'c' is a user-defined instance?


-- ?!ng

> On Mon, 28 Feb 2000, Guido van Rossum wrote:
> >
> > This is different. Maybe the docs are wrong; I always intended for
> > both max(a, b, ...) and max(seq) to be valid.

(BTW, I was wrong about the docs. The docs explain quite clearly
that max(a) is different from max(a, b, ...). Learning Python and
Python Essential Reference also document both forms.)

> I suppose in this case it's clear what you mean just from the
> number of arguments. But there is a potential surprise if someone
> who expects to have to say max(a, b, ...) then writes
>
> apply(max, tuple)
>
> and tuple turns out to only have one element. (I don't think
> i've ever realized that we could use min() or max() on a sequence.)

Yes, but there simply isn't any need to do this, so it won't occur in
practice.

> > (BTW, perhaps the __contains__ changes should be extended to __max__
> > and __min__? They share many of the same issues.)
>
> Indeed -- but then who do you trust? The first element of the
> sequence? Is it acceptable for
>
> max(a, b, c, d)
>
> to read as
>
> "a, please tell me which is the maximum among yourself, b, c, and d"
>
> ? Does 'a' then have to take care of the type-comparison logic
> for consistency with everything else? What if 'a' happens to be
> a built-in type but 'c' is a user-defined instance?

No, that's not what I meant. __min__ and __max__ would be methods of
sequences. The min() and max() functions would catch the special case
of multiple arguments and translate to min((a, b, ...)) etc. before
looking for __min__.

--Guido van Rossum (home page: http://www.python.org/~guido/)

From: Guido van Rossum <guido@python.org>

> (BTW, perhaps the __contains__ changes should be extended to __max__
> and __min__? They share many of the same issues.)

I suppose so, although I think the uses of a smart __contains__ are much
more frequent than the uses of a smart __max__.

On the other hand, I do think that it might be nice to have that sort of
hook in the rich array world...

On the topic of rich comparisons, I think I have a complete game plan in
my head, if not in code. I had to do some figuring out of the mods to
the compilation phase to allow short-circuiting with minimal performance
impact, as you and Jim H. discussed on the list way back when. But, as
you can guess, I'm a bit short on time. [.For those of you who don't
know, I have a 4-day old daughter at home, and, more relevantly, she has
an older brother =)].

I would really like a bit more discussion and decision on coercions
before finalizing the rich comparison patches, as I think a coherent
coercion strategy will help simplify the patches. Marc-Andre is short on
time due to the Unicode stuff, and he posted a teaser to spark some
discussion, which got no response at all. I'm not surprised, it's an
ugly problem. Did anyone have thoughts that they'd want to share on the
topic?

--david

> > (BTW, perhaps the __contains__ changes should be extended to __max__
> > and __min__? They share many of the same issues.)
>
> I suppose so, although I think the uses of a smart __contains__ are much
> more frequent than the uses of a smart __max__.

That's probably a reflection of the fact that min/max are less
frequently used than 'in'. (Which is reflected in making min/max
"mere" functions while 'in' is a built-in operator.)

I was thinking of any sequence representation that keeps its items
sorted (like the old ABC "lists"). Of course, if you're using a hash
table, 'in' is trivially answered, but min/max aren't.

> On the other hand, I do think that it might be nice to have that sort of
> hook in the rich array world...

Really? The min/max functions already do all their looping in C.

> On the topic of rich comparisons, I think I have a complete game plan in
> my head, if not in code. I had to do some figuring out of the mods to
> the compilation phase to allow short-circuiting with minimal performance
> impact, as you and Jim H. discussed on the list way back when. But, as
> you can guess, I'm a bit short on time. [.For those of you who don't
> know, I have a 4-day old daughter at home, and, more relevantly, she has
> an older brother =)].

[.I guess you get to worry about the older brother while your wife
takes care of the newborn? :-)]

> I would really like a bit more discussion and decision on coercions
> before finalizing the rich comparison patches, as I think a coherent
> coercion strategy will help simplify the patches. Marc-Andre is short on
> time due to the Unicode stuff, and he posted a teaser to spark some
> discussion, which got no response at all. I'm not surprised, it's an
> ugly problem. Did anyone have thoughts that they'd want to share on the
> topic?

I have no children [yet], but Python is my baby -- and I'm way
overcommitted to other Python projects. :-(

--Guido van Rossum (home page: http://www.python.org/~guido/)

> > On the other hand, I do think that it might be nice to have that
sort of
> > hook in the rich array world...
>
> Really? The min/max functions already do all their looping in C.

Right, but it might make sense to define min() on an array to mean
something different than what min-the-builtin could guess from whatever
__lt__ returns -- In fact, IIRC, min() on an array which implemented
rich comparisons would raise an exception. I don't want to specify the
semantics now (arrays are weird sequences), I just appreciate the hook.
The semantics would probably depend on the flavor of array one wanted to
use.

> [.I guess you get to worry about the older brother while your wife
> takes care of the newborn? :-)]

Got it it one.

--david

[DA]
> > > On the other hand, I do think that it might be nice to have that
> > > sort of hook in the rich array world...

[me]
> > Really? The min/max functions already do all their looping in C.

[DA]
> Right, but it might make sense to define min() on an array to mean
> something different than what min-the-builtin could guess from whatever
> __lt__ returns -- In fact, IIRC, min() on an array which implemented
> rich comparisons would raise an exception. I don't want to specify the
> semantics now (arrays are weird sequences), I just appreciate the hook.
> The semantics would probably depend on the flavor of array one wanted to
> use.

You're right.

I bet Moshe is already coding... (Tip: you could reuse the same flag
bit and simply rename it a bit, rather than having separate flag
bits. The binary compatibility requirement is only between released
versions, not between CVS versions.)

--Guido van Rossum (home page: http://www.python.org/~guido/)

[/F]
> appendnanny.py, anyone?

Yes, assuming nobody else has done so (there are still 200 new inbox msgs I
haven't gotten to yet!), I intend to write that tonight, and post it to the
patches list. grep is miserably inadequate for this task (I know -- I've it
on more than one occasion for this purpose).

nanny-nanny-ly y'rs - tim

[Guido]
> If it's not in the docs, where does everybody get the idea that this
> is legal? (The few cases in the std library are unlikely to be the
> only source; they were in pretty obscure places.)

[David Ascher]
> I think you're responsible for a little bit of the confusion.
<about append working being documentation enough>

David, you're taking Guido out of context: he did not say the "append" was
bad style, but that the "too inclusive excpetion" is bad style.

--
Moshe Zadka <mzadka@geocities.com>.
INTERNET: Learn what you know.
Share what you don't.

On Mon, 28 Feb 2000, Ka-Ping Yee wrote:

> > (BTW, perhaps the __contains__ changes should be extended to __max__
> > and __min__? They share many of the same issues.)
>
> Indeed -- but then who do you trust? The first element of the
> sequence? Is it acceptable for
>
> max(a, b, c, d)
>
> to read as
>
> "a, please tell me which is the maximum among yourself, b, c, and d"

Ping, I hardly think Python is going to ever have multi-methods...
Of course, __max__ (just like __add__ now) should (in some theoretical
definition of should) be implemented with multi-dispatch. See MAL's
suggestion for coercion for pragmatic (though not theoretic) possible
workarounds.

--
Moshe Zadka <mzadka@geocities.com>.
INTERNET: Learn what you know.
Share what you don't.

Moshe Zadka wrote:
> [Guido]
> > If it's not in the docs, where does everybody get the idea that this
> > is legal? (The few cases in the std library are unlikely to be the
> > only source; they were in pretty obscure places.)
>
> [David Ascher]
> > I think you're responsible for a little bit of the confusion.
> <about append working being documentation enough>
>
> David, you're taking Guido out of context: he did not say the "append" was
> bad style, but that the "too inclusive excpetion" is bad style.

yeah, but it wasn't, in this case -- the problem here is that
you've added TypeError to the list of exceptions that append
may raise, and that it does so on code that works perfectly
fine under 1.5.2.

...

David points out that Python lets you leave out the parens
around tuples in lots of places. consider:

"a = 1, 2, 3" vs. "a = (1, 2, 3)"
"a, b, c = a" vs. "(a, b, c) = a"
"a[a, b, c]" vs. "a[(a, b, c)]"

IOW, expecting 'append' to do what it did before is perfectly
reasonable (especially given 'extend'), also if you consider
what the library reference says:

s.append(x) -> same as s[len(s):len(s)] = [x]

s.extend(x) -> same as s[len(s):len(s)] = x
(raise exception if x is not a list)

a[k] -> the item of a with key k

a[k] = x -> set a[k] to x

...

but now that we have appendnanny, I don't really mind...

</F>

[/F]
> ...
> but now that we have appendnanny, I don't really mind...

Hmm -- I named *my* thing "checkappend". appendnanny would have been
inappropriate: the tabnanny is a merciless harpy nagging about things a
grownup should never have to worry about to begin with; i.e., a particularly
unpleasant type of nanny. I'm afraid lots of grownups are going to have a
short-term problem with the .append change, though. So they don't need a
nanny -- they need a tool unimaginatively named to reflect its oh-so-serious
purpose.

iow-the-tabnanny-holds-its-users-in-contempt-but-checkappend-
doesn't<wink>-ly y'rs - tim

> [Guido]
> > If it's not in the docs, where does everybody get the idea that this
> > is legal? (The few cases in the std library are unlikely to be the
> > only source; they were in pretty obscure places.)
>
> [David Ascher]
> > I think you're responsible for a little bit of the confusion.
> <about append working being documentation enough>

[Moshe]
> David, you're taking Guido out of context: he did not say the "append" was
> bad style, but that the "too inclusive excpetion" is bad style.

While that paragraph was placed ambiguously, I *did* mean it to apply
to multi-arg append(). It also applies to "too inclusive exception"
:-)

--Guido van Rossum (home page: http://www.python.org/~guido/)

> > What about adding a command-line switch for enabling warnings, as has
> > been suggested long ago? The .append() change could then print a
> > warning in 1.6alphas (and betas?), but still run, and be turned into
> > an error later.
>
> That's better. I propose that the warnings are normally on, and that
> there are flags to turn them off or thrn them into errors.

Can we then please have an interface to the "give warning" call (in stead of a
simple fprintf)? On the mac (and possibly also in PythonWin) it's probably
better to pop up a dialog (possibly with a "don't show again" button) than do
a printf which may get lost.
--
Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm