string slicing and method consistency

One of the students in my class at the Space Telescope Science Institute ("Hubble R Us") last week brought up an interesting point: if "abbc"[-1] is "c", and if "abbc".replace("b", "x", 1) is "axbc", then shouldn't "abbc".replace("b", "x", -1) be "abxc" (i.e. negative numbers replace the *last* occurrences of the value)? Same argument for "split", etc. Turns out that "abbc".replace("b", "x", -1) is "axxc" (i.e. negative arguments are ignored). I would have expected this to raise a ValueError, if anything. Is there a reason for this behavior? Is it worth making replace, split, etc. interpret negative indices in the same way as indexing does? Thanks, Greg

[GVW]
Dubious hypergeneralization. The thing is that this parameter, called maxsplit, is not really an index -- it's a count. Implementing this right would be tricky, because you'd really have to search for matches from the end (in order to make sense if there are overlapping matches possible, as in "abbbc".replace("bb", "BB", -1)). Where would this be useful? Is it ever useful for numbers smaller than -1? If all you typically want is replace the last occurrence, the rfind() method is your friend. --Guido van Rossum (home page: http://www.python.org/~guido/)

On Fri, Apr 20, 2001 at 04:48:06PM -0500, Guido van Rossum wrote:
[GVW]
Wouldn't it be nice if we could force particular arguments to be used as keyword arguments only ? :) I remember this coming up a few times on python-list, but I never quite understood why this isn't done. Syntax doesn't seem too much of a problem ('def split(s, sep, **, maxsplit=0)' comes to mind, and a new marker for PyArg_ParseTuple, like "**") and now that we have warnings and __future__, we could phase it in even for oft-used things such as string.split(). Even if it's deemed dubious hypergeneralization (look ma, no macro ;) it's worth writing a PEP about, right ? -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

Wouldn't it be nice if we could force particular arguments to be used as keyword arguments only ? :)
You could do this manually using **kwds (or its C equivalent), but it gets ugly.
Sure. My main problem with it is that I doubt how often it is useful, compared to the cost of adding the syntax and new code generation necessary. I don't think that ** is the right separator, but I don't have a better suggestion. --Guido van Rossum (home page: http://www.python.org/~guido/)

[GVW]
Dubious hypergeneralization. The thing is that this parameter, called maxsplit, is not really an index -- it's a count. Implementing this right would be tricky, because you'd really have to search for matches from the end (in order to make sense if there are overlapping matches possible, as in "abbbc".replace("bb", "BB", -1)). Where would this be useful? Is it ever useful for numbers smaller than -1? If all you typically want is replace the last occurrence, the rfind() method is your friend. --Guido van Rossum (home page: http://www.python.org/~guido/)

On Fri, Apr 20, 2001 at 04:48:06PM -0500, Guido van Rossum wrote:
[GVW]
Wouldn't it be nice if we could force particular arguments to be used as keyword arguments only ? :) I remember this coming up a few times on python-list, but I never quite understood why this isn't done. Syntax doesn't seem too much of a problem ('def split(s, sep, **, maxsplit=0)' comes to mind, and a new marker for PyArg_ParseTuple, like "**") and now that we have warnings and __future__, we could phase it in even for oft-used things such as string.split(). Even if it's deemed dubious hypergeneralization (look ma, no macro ;) it's worth writing a PEP about, right ? -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

Wouldn't it be nice if we could force particular arguments to be used as keyword arguments only ? :)
You could do this manually using **kwds (or its C equivalent), but it gets ugly.
Sure. My main problem with it is that I doubt how often it is useful, compared to the cost of adding the syntax and new code generation necessary. I don't think that ** is the right separator, but I don't have a better suggestion. --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (4)
-
Greg Wilson
-
Guido van Rossum
-
Ka-Ping Yee
-
Thomas Wouters