Re: Inconsistent reaction to extend
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] -- http://mail.python.org/mailman/listinfo/python-list
Re: Inconsistent reaction to extend
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Inconsistent reaction to extend
Jerzy Karczmarczuk wrote: 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 [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter -- http://mail.python.org/mailman/listinfo/python-list
Re: Inconsistent reaction to extend
On Fri, 09 Sep 2005 11:47:41 +0200, Jerzy Karczmarczuk wrote: 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. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Inconsistent reaction to extend
Op 2005-09-09, Steven D'Aprano schreef [EMAIL PROTECTED]: On Fri, 09 Sep 2005 11:47:41 +0200, Jerzy Karczmarczuk wrote: 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() -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Inconsistent reaction to extend
Antoon Pardon a écrit : 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() 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Inconsistent reaction to extend
Op 2005-09-09, Christophe schreef [EMAIL PROTECTED]: Antoon Pardon a écrit : 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() 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. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Inconsistent reaction to extend
Fredrik Lundh wrote: Jerzy Karczmarczuk wrote: 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. Yes it is :) then-there's-the-£10-argument-next-door-ly y'rs - steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Inconsistent reaction to extend
On Friday 09 September 2005 08:29 am, Steve Holden wrote: Yes it is :) That's not an argument! That's just a contradiction. I'm not payin' for this! -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com -- http://mail.python.org/mailman/listinfo/python-list
