Thu, 27 Jun 2002 23:40:00 -0400
> I just submitted a patch to the list.extend docstring, to reflect the fact
> that x.extend(xrange(10)) and x.extend((2,3)) both work when x is a list.
> Then I went to look at the documentation and noticed it says at
> s.extend(x) same as s[len(s):len(s)] = x (2)
Ya, that's no longer true.
> (2) Raises an exception when x is not a list object.
That's true of s[len(s}:len(s)] = x, but not of s.extend(x).
> The extend() method is experimental
"experimental" doesn't mean anything, so neutral on that <wink>.
> and not supported by mutable sequence types other than lists.
That's not true anymore either; for example, arrays (from the array module)
have since grown .extend() methods.
> Now I'm wondering what all this means.
Just that the docs are, as you suspect, out of date.
> It is /not/ equivalent to the slice assignment, because list slice
> assignment requires a list rhs.
Right. list.extend(x) actually requires that x be an iterable object. Even
works fine (and appends the lines of the file to the list).
> What does this "experimental" label mean?
I'm not sure. Guido slaps that label on new features from time to time,
with the implication that they may go away in the following release.
However, no *advertised* experimental feature has ever gone away, and I
doubt one ever will. We should drop the "experimental" on this one for sure
now, as lots of code uses list.extend().
> Is my patch to the docstring wrong, in the sense that it suggests
> exploiting undefined behavior in the same way that the old append
> -multiple-items behavior was undefined?
I haven't looked at the patch because you didn't include a handy link. It's
definitely intended that list.extend() accept iterable objects now.
> Also, I note that the table referenced above seems to be missing
> some right parentheses, at least on the .pop and .sort method
Yup, and they used to be there.
Thanks for the loan of the eyeballs!