[Python-Dev] Remove str.find in 3.0?
raymond.hettinger at verizon.net
Sun Aug 28 21:04:10 CEST 2005
> Also, as I understand Terry's request, .find() should be removed
> in favor of just leaving .index() (which is the identical method
> without the funny -1 return code logic).
> So your proposal really doesn't have all that much to do
> with Terry's request, but is a new and separate proposal
> (which does have some value in few cases, but not enough
> to warrant a new method).
It is new and separate, but it is also related. The core of Terry's
request is the assertion that str.find() is bug-prone and should not be
used. The principal arguments against accepting his request (advanced
by Tim) are that the str.index() alternative is slightly more awkward to
code, more likely to result in try-suites that catch more than intended,
and that the resulting code is slower. Those arguments fall to the
wayside if str.partition() becomes available as a superior alternative.
IOW, it makes Terry's request much more palatable.
> > def run_cgi(self):
> > """Execute a CGI script."""
> > dir, rest = self.cgi_info
> > rest, _, query = rest.rpartition('?')
> > script, _, rest = rest.partition('/')
> Wouldn't this do the same ?! ...
> rest, query = rest.rsplit('?', maxsplit=1)
> script, rest = rest.split('/', maxsplit=1)
No. The split() versions are buggy. They fail catastrophically when
the original string does not contain '?' or does not contain '/':
>>> rest = 'http://www.example.org/subdir'
>>> rest, query = rest.rsplit('?', 1)
Traceback (most recent call last):
File "<pyshell#10>", line 1, in -toplevel-
rest, query = rest.rsplit('?', 1)
ValueError: need more than 1 value to unpack
The whole point of str.partition() is to repackage str.split() in a way
that is conducive to fulfilling many of the existing use cases for
str.find() and str.index().
In going through the library examples, I've not found a single case
where a direct use of str.split() would improve code that currently uses
More information about the Python-Dev