This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Simple slice support for list.sort() and .reverse()
Type: enhancement Stage: patch review
Components: Interpreter Core Versions: Python 3.3
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: rhettinger Nosy List: collinwinter, hwundram, r.david.murray, rhettinger, terry.reedy
Priority: low Keywords: patch

Created on 2006-05-19 19:19 by hwundram, last changed 2022-04-11 14:56 by admin. This issue is now closed.

File name Uploaded Description Edit
python-sort-reverse.diff hwundram, 2006-05-20 11:18 Python list/array patches, with doc updates, V2.
Messages (8)
msg50292 - (view) Author: Heiko Wundram (hwundram) Date: 2006-05-19 19:19
As requested per

list.sort() should support extra keyword arguments
start and stop, which specify a slice of the whole list
to sort inplace.

The attached patch implements this functionality, and
extends the sorted() builtin to also offer these
keyword arguments, and additionally implements slice
support (also with start, stop) for list.reverse().

The patch updates the list object methods and the
sorted builtin, and also updates the testsuite to check
for the new keyword arguments and updates the
documentation to list them.
msg50293 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2006-05-20 05:14
Logged In: YES 

Having thought about submitting an RFE for start/stop for 
reverse, I support the enhancement.  Please do the same 
for array.reverse(, so list and array.reverse continue to 
have the same signature.  Two uses: one way to swap 
partitions in place is reverse each partition and then the 
whole sequence; probably more useful is the slice reversal 
in one standard method for sequentially generating 
permutations in lexicographical order.
msg50294 - (view) Author: Heiko Wundram (hwundram) Date: 2006-05-20 11:18
Logged In: YES 

The attached patch implements all of the old patch, and adds
the specified logic for array.reverse(), updates the
documentation for the array module and whatsnew25, and will
speed up the methods a slight little bit in the absense of
optimization when compiling Python.
msg50295 - (view) Author: Heiko Wundram (hwundram) Date: 2006-05-20 16:15
Logged In: YES 

By the way, I've just become aware of the fact that this
patch changes the semantics of list.sort() somewhat, because
of an optimization I did to the code. The DSU-function isn't
called anymore when there are less than two items to sort,
i.e. the list or the slice to sort is one item long. This means:

def test(k):
    return k[0]
x = [[1,2,3]]
print x

will now print [[1,2,3]] (with the patch applied), whereas
Python 2.4 would've printed [[1,2,3,4]], but not have called
timsort either.

I don't know whether this breaks anything (or the old
behaviour was sensible); at least it should have to be
documented. I'd like feedback before I start either taking
out the optimization or documenting this.
msg50296 - (view) Author: Collin Winter (collinwinter) * (Python committer) Date: 2007-03-09 03:07
I think anyone who was relying on that behavior was treading on "implementation details" territory to begin with, so I wouldn't worry about this particular semantics nit.
msg110831 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2010-07-19 22:59
I can't see any sense in doing a patch review on this until there is agreement that the patch is actually needed.  Having read the initially referenced thread on I'm not convinced that this is going to happen.
msg113671 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2010-08-12 09:53
I'm rejecting this feature request on the grounds that the use cases are sufficiently uncommon to warrant adding API complexity.  

Currently, the notions of reverse() and sort() are comparatively simple.  They correspond well to what I see in other languages.

Another issue is orthogonality, keeping the notions of slicing separate from concerns about sorting and reversing.

Also, the optimization aspect of this feature request is misguided (trying to reduce an O(n) step embedded inside an O(n log n) operation.

The purported syntactic gain is also negligible and uncompelling.
The rare bit of code that currently is written:

  sorted(s[a:b], key=f)

would instead become:

  sorted(s, key=f, start=a, stop=b)

There is no significant syntactic win or gain in expressiveness.
msg117161 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-09-23 01:04
In fact, I find the proposed syntax *less* obvious than the slice syntax, for sorted.  IOW, I'd be -1 on adding these to sorted.  The potentially useful case is between

    l[a:b] = sorted(l[a:b})


    l.sort(start=a, stop=b)

where the interesting bit is that the sort takes place in place (no memory copy).

I still find the slice syntax clearer :), and it's not clear that the savings of the memory copy for a few programs that use it is worth the added complexity for all other programs.  So I concur with Raymond's rejection.
Date User Action Args
2022-04-11 14:56:17adminsetgithub: 43382
2010-09-23 01:04:50r.david.murraysetnosy: - BreamoreBoy
2010-09-23 01:04:32r.david.murraysetnosy: + r.david.murray
messages: + msg117161
2010-08-12 09:53:33rhettingersetstatus: open -> closed
resolution: rejected
messages: + msg113671
2010-08-11 20:04:45rhettingersetpriority: normal -> low
assignee: rhettinger

nosy: + rhettinger
versions: + Python 3.3, - Python 3.2
2010-08-09 04:22:27terry.reedysetversions: + Python 3.2, - Python 3.1, Python 2.7
2010-07-19 22:59:34BreamoreBoysetnosy: + BreamoreBoy
messages: + msg110831
2009-03-21 02:46:04ajaksu2setstage: patch review
type: enhancement
versions: + Python 3.1, Python 2.7, - Python 2.5
2006-05-19 19:19:08hwundramcreate