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
On Fri, 20 Apr 2001, Greg Wilson wrote:
Is it worth making replace, split, etc. interpret negative indices in the same way as indexing does?
I think this would be really cool in particular for split(). (And if it worked for split it would have to work for replace.) -- ?!ng
[GVW]
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?
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]
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?
Dubious hypergeneralization. The thing is that this parameter, called maxsplit, is not really an index -- it's a count.
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
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.
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 ?
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