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. -- Zachary Burns (407)590-4814 Aim - Zac256FL Production Engineer (Digital Overlord) Zindagi Games
On Tue, May 05, 2009 at 09:25:16AM -0700, Zac Burns wrote:
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.
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:
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:
On Tue, May 5, 2009 at 1:11 PM, Jeremy Banks <jeremy@jeremybanks.ca> wrote:
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:
Sorry for previously top-posting, something I need to get used to. I'm +1 for the reversed parameter over 'r' methods. -- Zachary Burns (407)590-4814 Aim - Zac256FL Production Engineer (Digital Overlord) Zindagi Games
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:
-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 Tue, May 5, 2009 at 7:31 PM, Steven D'Aprano <steve@pearwood.info> wrote:
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(), 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]. George [1] http://www.google.com/codesearch?hl=en&start=10&sa=N&filter=0p&q=lang:python+package:svn.python.org/projects/python/trunk+%3D(True|False)
On Wed, 6 May 2009 10:45:32 am George Sakkis wrote:
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.
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
steve@pearwood.info wrote:
What other built-in functions take a bool param to select between different functionality? sorted() is a special case.
Another thing about sort() is that reversed=True is equivalent to passing a key function that results in reversed ordering, so it's easy to see it as a parameterization of the existing behaviour. That's not the case with index() and remove() -- there's nothing you can pass to the existing methods that will cause them to operate in reverse. -- Greg
On Wed, 6 May 2009 02:27:18 pm Terry Reedy wrote:
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
On Wed, May 6, 2009 at 1:03 AM, Steven D'Aprano <steve@pearwood.info> wrote:
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
On Tue, May 05, 2009 at 09:25:16AM -0700, Zac Burns wrote:
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.
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:
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:
On Tue, May 5, 2009 at 1:11 PM, Jeremy Banks <jeremy@jeremybanks.ca> wrote:
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:
Sorry for previously top-posting, something I need to get used to. I'm +1 for the reversed parameter over 'r' methods. -- Zachary Burns (407)590-4814 Aim - Zac256FL Production Engineer (Digital Overlord) Zindagi Games
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:
-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 Tue, May 5, 2009 at 7:31 PM, Steven D'Aprano <steve@pearwood.info> wrote:
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(), 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]. George [1] http://www.google.com/codesearch?hl=en&start=10&sa=N&filter=0p&q=lang:python+package:svn.python.org/projects/python/trunk+%3D(True|False)
On Wed, 6 May 2009 10:45:32 am George Sakkis wrote:
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.
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
steve@pearwood.info wrote:
What other built-in functions take a bool param to select between different functionality? sorted() is a special case.
Another thing about sort() is that reversed=True is equivalent to passing a key function that results in reversed ordering, so it's easy to see it as a parameterization of the existing behaviour. That's not the case with index() and remove() -- there's nothing you can pass to the existing methods that will cause them to operate in reverse. -- Greg
On Wed, 6 May 2009 02:27:18 pm Terry Reedy wrote:
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
On Wed, May 6, 2009 at 1:03 AM, Steven D'Aprano <steve@pearwood.info> wrote:
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
participants (14)
-
Carl Johnson -
CTO -
George Sakkis -
Greg Ewing -
Jared Grubb -
Jeremy Banks -
John Graham -
Mathias Panzenböck -
MRAB -
Oleg Broytmann -
steve＠pearwood.info -
Steven D'Aprano
-
Terry Reedy -
Zac Burns