Inconsistent reaction to extend

[Jerzy Karczmarczuk]

Gurus, before I am tempted to signal this as a bug, perhaps
you might convince me that it should be so. If I type

l=range(4)
l.extend([1,2])

l gives [0,1,2,3,1,2], what else...

On the other hand, try

p=range(4).extend([1,2])

Then, p HAS NO VALUE (NoneType).

With append the behaviour is similar. I didn't try other methods, but
I suspect that it won't improve.


WHY?
It seems that there was already some discussion about consistency and
somebody produced the example: h = {}.update(l) which didn't work,
but I wasn't subscribed to this nsgr, I couldn't follow this affair.

Jerzy Karczmarczuk

 

[Timo]

Jerzy Karczmarczuk kirjoitti:

On the other hand, try

p=range(4).extend([1,2])

Then, p HAS NO VALUE (NoneType).

With append the behaviour is similar. I didn't try other methods, but
I suspect that it won't improve.


WHY?

range(4) returns a list and Python's list.extend() returns None. Extend
is a in-place operation.

-- timo

 

[Fredrik Lundh]

Gurus, before I am tempted to signal this as a bug, perhaps
you might convince me that it should be so.

it's not a bug, and nobody should have to convince you about any-
thing; despite what you may think from reading certain slicing threads,
this mailing list is not an argument clinic.

If I type

l=range(4)
l.extend([1,2])

l gives [0,1,2,3,1,2], what else...

On the other hand, try

p=range(4).extend([1,2])

Then, p HAS NO VALUE (NoneType).

(footnote: None is a value in Python. it can be used to represent "no value",
but it can also be used for other things)

With append the behaviour is similar. I didn't try other methods, but
I suspect that it won't improve.

WHY?

because you're saving the return value of "extend", not "range", and "extend"
returns None.

if you split it up like this

l = range(4)
p = l.extend([1, 2])

it should be obvious that "l" and "p" doesn't necessarily contain the same thing.

</F>

 

[Robert Kern]

Gurus, before I am tempted to signal this as a bug, perhaps
you might convince me that it should be so. If I type

l=range(4)
l.extend([1,2])

l gives [0,1,2,3,1,2], what else...

On the other hand, try

p=range(4).extend([1,2])

Then, p HAS NO VALUE (NoneType).

With append the behaviour is similar. I didn't try other methods, but
I suspect that it won't improve.

WHY?

..append(), .extend(), .sort() (as well as .update() for dictionaries)
all are methods whose *only* effect is to modify the object in-place.
They return None as a reminder that they do modify the object instead of
copying the object and then modifying the copy. From the FAQ[1] with
respect to .sort():

"""This way, you won't be fooled into accidentally overwriting a list
when you need a sorted copy but also need to keep the unsorted version
around."""

[1]
http://www.python.org/doc/faq/general.html#why-doesn-t-list-sort-return-the-sorted-list

--
Robert Kern
(e-mail address removed)

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

 

[Steven D'Aprano]

Gurus, before I am tempted to signal this as a bug, perhaps
you might convince me that it should be so. If I type

l=range(4)
l.extend([1,2])

l gives [0,1,2,3,1,2], what else...

That is correct. range() returns a list. You then call the extend method
on that list. Extend has deliberate side-effects: it operates on the list
that calls it, it does not create a new list.

On the other hand, try

p=range(4).extend([1,2])

Then, p HAS NO VALUE (NoneType).

p has the value None, which is also correct. The extend() method returns
None, it does not create a new list. There is nothing inconsistent about
it. Unintuitive, perhaps. Unexpected, maybe. But not inconsistent.

[snip]

WHY?

Because creating a new list is potentially very time-consuming and
expensive of memory. Imagine you have a list of 100,000 large objects, and
you want to add one more object to it. The way Python works is that append
and extend simply add that new object to the end of the existing list. The
way you imagined it would work would require Python to duplicate the
entire list, all 100,000 large objects, plus the extra one.

 

[Antoon Pardon]

Gurus, before I am tempted to signal this as a bug, perhaps
you might convince me that it should be so. If I type

l=range(4)
l.extend([1,2])

l gives [0,1,2,3,1,2], what else...

That is correct. range() returns a list. You then call the extend method
on that list. Extend has deliberate side-effects: it operates on the list
that calls it, it does not create a new list.

On the other hand, try

p=range(4).extend([1,2])

Then, p HAS NO VALUE (NoneType).

p has the value None, which is also correct. The extend() method returns
None, it does not create a new list. There is nothing inconsistent about
it. Unintuitive, perhaps. Unexpected, maybe. But not inconsistent.

[snip]

WHY?

Because creating a new list is potentially very time-consuming and
expensive of memory. Imagine you have a list of 100,000 large objects, and
you want to add one more object to it. The way Python works is that append
and extend simply add that new object to the end of the existing list. The
way you imagined it would work would require Python to duplicate the
entire list, all 100,000 large objects, plus the extra one.

This has nothing to do with the need to create a new list.

The extend method could just have returned self. Just as sort and reverse could
have done so. This would have made it possible to do things like the following:

lst.sort().reverse()

instead of having to write:

lst.sort()
lst.reverse()

 

[Christophe]

Antoon Pardon a écrit :

This has nothing to do with the need to create a new list.

The extend method could just have returned self. Just as sort and reverse could
have done so. This would have made it possible to do things like the following:

lst.sort().reverse()

instead of having to write:

lst.sort()
lst.reverse()

This was done on purpose to avoid a second class of problems. The one
where you forget that reverse modifies the list in place. That second
class of problems was deemed more dangerous because it works without
immediate errors.

 

[Antoon Pardon]

Antoon Pardon a écrit :

This was done on purpose to avoid a second class of problems.

I know, but I didn't think it was relevant enough for what I was addressing.

The one
where you forget that reverse modifies the list in place. That second
class of problems was deemed more dangerous because it works without
immediate errors.

I know this is the explanation that is frequently given, but I find
that rather weak. IMO one could argue that the following code
has the same kind of problem as you mention.

lst2 = lst1
lst1.reverse()

If you forget that lst2 is not a copy of lst1 but just an other
name for the same object you are in trouble too and this too
works without immediate errors. So why should lst.sort().reverse()
be so much more dangerous?

Well it doesn't matter much. Python will probably not change in
this respect in the future, so unless you can give me an
argument I haven't heard before I'll just drop this.

 

[Steve Holden]

Jerzy Karczmarczuk wrote:




it's not a bug, and nobody should have to convince you about any-
thing; despite what you may think from reading certain slicing threads,
this mailing list is not an argument clinic.

Yes it is

then-there's-the-£10-argument-next-door-ly y'rs - steve

 

[Terry Hancock]

Yes it is

That's not an argument! That's just a contradiction.

I'm not payin' for this!

 

[Bruno Desthuilliers]

Jerzy Karczmarczuk a écrit :

Gurus,

No guru answered, so you'll have to bear with me...

before I am tempted to signal this as a bug, perhaps
you might convince me that it should be so. If I type

l=range(4)
l.extend([1,2])

l gives [0,1,2,3,1,2], what else...

On the other hand, try

p=range(4).extend([1,2])

Then, p HAS NO VALUE (NoneType).

But it does have a value : None. And no need to shout, we here you
pretty well.

Two questions :
1/ Do you *really* think that, *if* it was a bug, no-one would have
noticed ? Seriously ?

2/ Did you Read The Fine Manual(tm) ?

WHY?

BECAUSE!

'destructive' methods like append, extend, sort etc return None, so you
cannot use'em without knowing they are destructive. Rationale is that it
helps the non-programmers avoiding shooting themselves in the foot. I
personnaly find it's a PITA, but what, you'll have to live with it, or
use another language - I, personnaly, choosed to live with it.

BTW, what's wrong with:
p = range(4) + [1, 2]