Movatterモバイル変換

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

• Previous message:[Python-Dev] [Python-checkins] python/dist/src/Lib/testtest_bz2.py, 1.18, 1.19
• Next message:[Python-Dev] Remove str.find in 3.0?
• Messages sorted by:[ date ][ thread ][ subject ][ author ]

Can str.find be listed in PEP 3000 (under builtins) for removal?Would anyone really object?Reasons:1. Str.find is essentially redundant with str.index.  The only difference is that str.index Pythonically indicates 'not found' by raising an exception while str.find does the same by anomalously returning -1.  As best as I can remember, this is common for Unix system calls but unique among Python builtin functions.  Learning and remembering both is a nuisance.2. As is being discussed in a current c.l.p thread, -1 is a legal indexing subscript.  If one uses the return value as a subscript without checking, the bug is not caught.  None would be a better return value should find not be deleted.3. Anyone who prefers to test return values instead of catch exceptions can write (simplified, without start,end params):def sfind(string, target):  try:    return string.index(target)  except ValueError:    return None # or -1 for back compatibility, but None betterThis can of course be done for any function/method that indicates input errors with exceptions instead of a special return value.  I see no reason other than history that this particular method should be doubled.If .find is scheduled for the dustbin of history, I would be willing to suggest doc and docstring changes.  (str.index.__doc__ currently refers to str.find.__doc__.  This should be reversed.)Terry J. Reedy

• Previous message:[Python-Dev] [Python-checkins] python/dist/src/Lib/testtest_bz2.py, 1.18, 1.19
• Next message:[Python-Dev] Remove str.find in 3.0?
• Messages sorted by:[ date ][ thread ][ subject ][ author ]