[Python-bugs-list] [ python-Feature Requests-547481 ] In-place reverse() and sort() for slices

noreply@sourceforge.net noreply@sourceforge.net
Fri, 03 Jan 2003 01:01:49 -0800


Feature Requests item #547481, was opened at 2002-04-23 04:48
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=547481&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Bernhard Bender (bbender)
Assigned to: Nobody/Anonymous (nobody)
Summary: In-place reverse() and sort() for slices

Initial Comment:
In order to apply sort() or reverse() to only part of a
sequence (a slice), the following code seems to be
necessary:

	# a is a sequence
	tmp = s[m:n]
	tmp.sort()		# or tmp.reverse()
	s[m:n] = tmp

It would be much nicer to apply sort() or reverse() to
the slice directly:

	a[m:n].sort()

However, this does not work, since the slice returns a
new sequence object, on which sort() or reverse() will
work, instead of working on the slice in-place.
After sort() is done, the modified object will be
discarded, since it cannot be assigned to anything as
sort() and reverse() do not have a return value.

Therefore, the line above is accepted by the
interpreter even though it is completely useless.

My proposal is to change the semantics of applying
sort() and reverse() to slices such as to work in-place
on the slice, in stead of working on the new object
created by the slicing operation.

This would be similar to slice assignment, which also
does not create a new object.

Would this change require a PEP?

Bernhard Bender

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 04:01

Message:
Logged In: YES 
user_id=80475

I agree with Martin that the idea is unworkable as 
proposed.  As of Py2.3a, the need has been met (to some 
degree) through extended slice notation. Also, it has been 
seven months since last hearing from the OP. Marking as 
closed.




----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-09 09:23

Message:
Logged In: YES 
user_id=21627

I'm still not clear what it is that you are requesting. It
appears that you want

  x[m:n].reverse()

to be the reversed slice. One way to achieve this is to 
have .reverse return the object it operates on, instead of
None (which it currently returns). This has been rejected
before.

The other option is that

  x[m:n]

does not return a new list, but some kind of "slice object",
which has a reverse operation that has a different meaning
from the reverse operation of lists. This is a
backwards-incompatible change, since people rely on x[m:n]
returning a list if x is a list.

I can see no third approach to make this work. Can you?

----------------------------------------------------------------------

Comment By: Bernhard Bender (bbender)
Date: 2002-04-25 07:45

Message:
Logged In: YES 
user_id=523837

I do not see this as a major change to the language:

1- slicing a[n:m] already has two different semantics
(creating a new object or referring to a slice of the
original sequence) depending on wether it is on the right or
left side of an assigment operator

2- statements like a[n:m].reverse() currently have no net
effect on any program, so they should not be used in any
well tested software.

3- I am not proposing to change the semantics of any current
use of slicing, especially a slice will still return a new
object.

The only change is for the application of in-place
operations like sort() and reverse() that currently make no
sense with slices.
Therefore, such change to the semantics of slicing should be
possible without doing harm to any existing program,
especially if an "import from __future__" is use to activate
the new semantics.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-04-23 17:17

Message:
Logged In: YES 
user_id=35752

This would take some deep magic to make work and would
be a fundamental change to the language.  lst[m:m] is an
expression that returns a new object.  The chances of this
change being accepted is about zero.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=547481&group_id=5470