On 5 May 2009, at 09:49, Oleg Broytmann wrote:

On Tue, May 05, 2009 at 09:25:16AM -0700, Zac Burns wrote:

...

I would like to see the following methods added to lists...

rindex : Return first index of value from the right rremove: Return first occurence of value from the right.

l.rremove() is the same as l.pop() or l.pop(-1)

No, pop removes an element; rremove removes an element of a given value. Jared

Jeremy is correct... Sorry, there was a typo in the proposal. This: "rremove: Return first occurence of value from the right." Should read: "rremove: Remove first occurence of value from the right." The methods are 'inspired' by the similar 'r' methods of strings. -- Zachary Burns (407)590-4814 Aim - Zac256FL Production Engineer (Digital Overlord) Zindagi Games On Tue, May 5, 2009 at 10:11 AM, Jeremy Banks <jeremy@jeremybanks.ca> wrote:

I believe the proposal is to have l.rremove() take a value parameter, and remove the last occurrence of that value from the list, not just the last value in the list.

My assumpting is that their basic functionality would work like this.

   l = [1, 2, 3, 2, 1]    l.rindex(2) == 3    l.rremove(2)    l == [1, 2, 3, 1]

I'd say +1.

On 2009-05-05, Oleg Broytmann <phd@phd.pp.ru> wrote:

...

On Tue, May 05, 2009 at 09:25:16AM -0700, Zac Burns wrote:

...

I would like to see the following methods added to lists...

rindex : Return first index of value from the right rremove: Return first occurence of value from the right.

   l.rremove() is the same as l.pop() or l.pop(-1)

Oleg. --      Oleg Broytmann            http://phd.pp.ru/            phd@phd.pp.ru            Programmers don't die, they just GOSUB without RETURN. _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

On Tue, May 5, 2009 at 1:11 PM, Jeremy Banks <jeremy@jeremybanks.ca> wrote:

I believe the proposal is to have l.rremove() take a value parameter, and remove the last occurrence of that value from the list, not just the last value in the list.

My assumpting is that their basic functionality would work like this.

   l = [1, 2, 3, 2, 1]    l.rindex(2) == 3    l.rremove(2)    l == [1, 2, 3, 1]

I'd say +1.

The functionality would be useful but instead of polluting the API with various "r*" methods, I'd prefer a `reversed=False` boolean parameter wherever it makes sense, just like sort(ed). I.e. instead of list.rindex -> list.index(reversed=True) and list.rremove -> list.remove(reversed=True). George

I've tried to 'r' search the list using the start/stop parameters to no avail. l = [1, 2, 3, 2, 1] l.index(2, 0, 4) == 1 # True l.index(2, 4, 0) # ValueError l.index(2, -1, 0) # ValueError -- Zachary Burns (407)590-4814 Aim - Zac256FL Production Engineer (Digital Overlord) Zindagi Games On Tue, May 5, 2009 at 10:48 AM, MRAB <google@mrabarnett.plus.com> wrote:

Zac Burns wrote:

...

I would like to see the following methods added to lists...

rindex : Return first index of value from the right rremove: Return first occurence of value from the right.

index() has start and stop arguments. Would anything be gained if remove() had them too? _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

Would there be any interest in adding a 'reversed' kwarg to the relevant string methods, deprecating the r-methods in Python 3.2, and removing them in Python 3.3? It might make things a little simpler and unclutter the dir for strings a bit…

On Wed, 6 May 2009 06:20:31 am Carl Johnson wrote:

Would there be any interest in adding a 'reversed' kwarg to the relevant string methods, deprecating the r-methods in Python 3.2, and removing them in Python 3.3? It might make things a little simpler and unclutter the dir for strings a bit…

-0.5 from me. I think a "reversed" argument clutters up the signature of the various find() methods (etc) for little or no benefit, and certainly not enough benefit to make up for the hassle of going through the depreciation process and breaking compatibility with existing code. A "reversed" kwarg would only be useful when you don't know which direction you want to search in until runtime. How often does that happen? In practice, I believe you will nearly always know whether you want to search from the left or the right when you're writing the code. so I expect the "reversed" kwarg will nearly always be given as a constant: astring.find("spam", reversed=True) as opposed to: astring.find("spam", reversed=(today==Wednesday)) A slightly whimsical example, but I hope it illustrates the point. On the rare occasion that you do need a flag to distinguish "operate from the left" from "operate from the right", I don't believe it is a hardship to use something like the following idiom: def func(astring, arg, ... , reversed=False): if reversed: find = astring.find else: find = astring.rfind ... n = find(arg) -- Steven D'Aprano

On Wed, 6 May 2009 10:45:32 am George Sakkis wrote:

...

A "reversed" kwarg would only be useful when you don't know which direction you want to search in until runtime. How often does that happen? In practice, I believe you will nearly always know whether you want to search from the left or the right when you're writing the code. so I expect the "reversed" kwarg will nearly always be given as a constant:

astring.find("spam", reversed=True)

as opposed to:

astring.find("spam", reversed=(today==Wednesday))

A slightly whimsical example, but I hope it illustrates the point.

Sorry, that doesn't make much sense. Not only list.sort()/sorted() use exactly this API and we (thankfully) don't have list.rsort()/rsorted(),

list.sort() and sorted() are a very different situation. There was no depreciated reversesort() function to worry about when the reverse param was added. What we used to have is alist.sort() alist.reverse() For obvious reasons, that can't be written as alist.sort().reverse() Personally, I don't dislike the two-line version, but given that sorted() has a reverse flag, I accept that sort() should get one too for consistency. As for sorted(), remember that reversed() returns an iterator, not a list. So without a reverse param, you would need to write: list(reversed(sorted(alist))) but that's nasty for something as common as reversing a sorted list.

but that argument could be used against almost all functions with boolean parameters, since they are typically called with a constant True or False [1].

And I would exactly make that argument. What other built-in functions take a bool param to select between different functionality? sorted() is a special case. Anything else? I can't think of anything off the top of my head, but maybe that's just me. While I won't put words into Guido's mouth, I believe he has made that argument in the past. If your function takes a bool param to switch between two different behaviours, that's a good sign that it should be two functions rather than one. -- Steven D'Aprano

Carl Johnson wrote:

Would there be any interest in adding a 'reversed' kwarg to the relevant string methods, deprecating the r-methods in Python 3.2, and removing them in Python 3.3? It might make things a little simpler and unclutter the dir for strings a bit…

I personally would strongly prefer a reverse keyward and would not mind de-cluttering the current set of methods too.

On Wed, May 6, 2009 at 1:03 AM, Steven D'Aprano <steve@pearwood.info> wrote:

On Wed, 6 May 2009 02:27:18 pm Terry Reedy wrote:

...

Carl Johnson wrote:

...

Would there be any interest in adding a 'reversed' kwarg to the relevant string methods, deprecating the r-methods in Python 3.2, and removing them in Python 3.3? It might make things a little simpler and unclutter the dir for strings a bit…

I personally would strongly prefer a reverse keyward and would not mind de-cluttering the current set of methods too.

Do you have any use-cases where you don't know whether you want forward or reverse search until runtime?

That is, where you currently write something like:

if some_var:    n = astring.find(target) else:    n = astring.rfind(target)

or equivalent?

-- Steven D'Aprano _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

I may be over architecting, but the combination of a separate function to distinguish between two different behaviors, especially something as cross cutting as doing something in reverse, seems a lot like a builder pattern. Something like the following, though I doubt the following syntax would be seen at all as pretty: lst.reversed().find(target) #rfind lst.find(target) #left find you can already do this with the following reversed(lst).find(target) but this is pretty inefficient. the purpose of a builder pattern like series of functions to 'configure' whether you want to search from the left or right would be that the 'reversed()' function in the first example wouldn't actually reverse the list, but instead reverse which side the next function that was called operated from. I don't know if that's really that possible within the language. -JG