[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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4