A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2005-August/055800.html below:

[Python-Dev] Remove str.find in 3.0?

[Python-Dev] Remove str.find in 3.0? [Python-Dev] Remove str.find in 3.0?Terry Reedy tjreedy at udel.edu
Tue Aug 30 06:54:50 CEST 2005
"Raymond Hettinger" <raymond.hettinger at verizon.net> wrote in message 
news:001501c5ac03$4679e480$d206a044 at oemcomputer...
> [M.-A. Lemburg]
>> 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).

My proposal is to use the 3.0 opportunity to improve the language in this 
particular area.  I considered and ranked five alternatives more or less as 
follows.

1. Keep .index and delete .find.
2. Keep .index and repair .find to return None instead of -1.
3.5 Delete .index and repair .find.
3.5 Keep .index and .find as is.
5. Delete .index and keep .find as is.

> It is new and separate, but it is also related.

I see it as a 6th option: keep.index, delete .find, and replace with 
.partition.  I rank this at least second and maybe first.  It is separable 
in that the replacement can be done now, while the deletion has to wait.

> The core of Terry's request is the assertion that str.find()
> is bug-prone and should not be used.

That and the redundancy, both of which bothered me a bit since I first 
learned the string module functions.

Terry J. Reedy



More information about the Python-Dev mailing list

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