Python vs. Ruby

[Bengt Richter]

On Wed, 1 Jan 2003 18:15:49 -0500, "John Roth" <johnroth at ameritech.net> wrote:

>
>"Peter Hansen" <peter at engcorp.com> wrote in message
>news:3E137008.3586A4D8 at engcorp.com...
>> Rob Renaud wrote:
>> >
>> > <lot snipped>
>> > "John Roth" <johnroth at ameritech.net> wrote in message
>> > > Whether append() returns a *new* object or not is irrelevant to
>> > > my arguement. The fact that it returns None is the wart.
>> > >
>> > > John Roth
>> >
>> > It's consistant, not a wart from my perspective.  If an object is
>> > modified, it is not returned.
>> >
>> > For every part of the (admittedly small) python library I know, that
>> > is the case.  Returning None is a hint that the object is modified.
>
>I wasn't aware that it was a consistent policy. That doesn't mean it
>isn't, just that I wasn't aware of it if it is.
>
>> > So then the question becomes, why don't append(), sort(), reverse()
>> > return a new list and not modify the original?  Are mutable objects
>> > themselves a wart on the langauge?
>>
>> I believe the response might be that, in at least the case of sort(),
>> and probably reverse() as well, creation of a new list would require
>> twice the memory, at least temporarily, which can be very undesirable.
>
>That's what I've always heard. In the case of .sort() and .reverse() the
>performance hit (other than for storage allocation) would be neglible,
>but for
>.append() it involves copying the entire list as well as allocating
>storage.

Surely large lists would not be copied for every append? Wouldn't the
space be expanded in chunks? Even 1% extra free space for a million-item
list would give you 10k appends without reallocation and copying.

Regards,
Bengt Richter