Re: Equivalents of Ruby's "!" methods?

[Terry Reedy]

Paul McGuire wrote:

Pythonistically speaking, even though a dict is a mutable thing, I'm
learning that the accepted practice for methods like this is not so
much to update in place as it is to use generator expressions to
construct a new object.

I disagree. The convention is that mutation methods should return None.

For example, given a list of integers to 100,
instead of removing all of the even numbers (with the attendant
hassles of updating a list while iterating over it), just create a new
list of the numbers that are not even.

This is because each removal is O(n), making the entire process O(n*2),
whereas a new list is O(n) -- and the hassle of remembering to iterate
in reverse when doing removals.

Perhaps I am overgeneralizin g from comments I have read here on c.l.py
about creating new lists instead updating old ones.

I think so. Removals and insertions are importantly different from
change in place. If I wanted to square each number in a list, and *did
not need the original list*, I would not hesitate to do it in place.

The newish sorted() and reversed() built-ins were meant to complement
list.sort and list.reverse, not replace them.

tjr

[Grzegorz Staniak]

Re: Equivalents of Ruby's "!&quot ; methods?

On 25.08.2008, Terry Reedy <tjreedy@udel.e duwroted:

The newish sorted() and reversed() built-ins were meant to complement
list.sort and list.reverse, not replace them.

BTW, is there a reason why sorted() on a list returns a list, while
reversed() on the same list returns an iterator?

GS
--
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>

[Fredrik Lundh]

Re: Equivalents of Ruby's &quot;!&quot ; methods?

Grzegorz Staniak wrote:

BTW, is there a reason why sorted() on a list returns a list, while
reversed() on the same list returns an iterator?

the algorithm required to sort a sequence is something entirely
different from the algorithm required to loop over a sequence in
reverse. we went through this a few days ago.

</F>

[Steven D'Aprano]

Re: Equivalents of Ruby's &quot;!&quot ; methods?

On Mon, 25 Aug 2008 17:04:07 +0000, Grzegorz Staniak wrote:

On 25.08.2008, Terry Reedy <tjreedy@udel.e duwroted:
>

>The newish sorted() and reversed() built-ins were meant to complement
>list.sort and list.reverse, not replace them.

>
BTW, is there a reason why sorted() on a list returns a list, while
reversed() on the same list returns an iterator?

Until the day that somebody discovers how to sort a list without seeing
all the items first, there's no point in sorted() returning an iterator.
It has to generate a copy of the entire list to sort it, and so might as
well just return the list -- there's no advantage to turning it into an
iterator after you've already built the list.

On the other hand, reversed() can supply it's items lazily. Although it
does need access to the entire source, it doesn't need to return an
entire list. It can just return the items one at a time, starting from
the last one.

That however does mean there's one gotcha: if you mutate a list after
calling sorted() on it, the result of the sorted() doesn't change. But
the same doesn't hold for reversed():

>>L = range(5)
>>it = reversed(L) # expecting [4, 3, 2, 1, 0] as an iterator
>>it.next()

4

>>L[3] = 'mutate'
>>it.next()

'mutate'

The solution to that is simple: call list(reversed(L )). Or don't mutate
the original.



--
Steven

[mumbler@gmail.com]

Re: Equivalents of Ruby's &quot;!&quot ; methods?

On Aug 26, 9:47 am, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com .auwrote:

On Mon, 25 Aug 2008 17:04:07 +0000, Grzegorz Staniak wrote:

On 25.08.2008, Terry Reedy <tjre...@udel.e duwroted:

>

The newish sorted() and reversed() built-ins were meant to complement
list.sort and list.reverse, not replace them.

>

BTW, is there a reason why sorted() on a list returns a list, while
reversed() on the same list returns an iterator?

>
Until the day that somebody discovers how to sort a list without seeing
all the items first, there's no point in sorted() returning an iterator.

To nitpick, this is not strictly true: sure, you're at best O(nlogn)
on sorting the entire list, but you could return the first element of
the 'sorted' list in O(n) (if you don't mind using a O(n^2) algorithm
for the whole sort). i.e. if you have a use case where you're only
likely to look at the first few elements of a sorted list, it would
make some sense to have an iterator.