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

[Wolfgang Lipp]

On Sat, 27 Aug 2005 08:54:12 +0200, Martin v. Löwis <martin at v.loewis.de>  
wrote:
> with choice 1a): dict.get returns None if the key is not found, even
> though None could also be the value for the key.

that's a bug! i had to *test* it to find out it's true! i've been writing
code for *years* all in the understanding that dict.get(x) acts precisely
like dict['x'] *except* you get a chance to define a default value. which,
for me, has become sort of a standard solution to the problem the last ten
or so postings were all about: when i write a function and realize that's
one of the cases where python philosophy strongly favors raising an  
exception
because something e.g. could not be found where expected, i make it so that
a reasonable exception is raised *and* where meaningful i give consumers
a chance to pass in a default value to eschew exceptions. i believe
this is the way to go to resolve this .index/.find conflict. and, no,
returning -1 when a substring is not found and None when a key is not
found is *highly* problematic. i'd sure like to see cases like that to go.

i'm not sure why .rindex() should go (correct?), and how to do what it does
(reverse the string before doing .index()? is that what is done  
internally?)

and of course, like always, there is the question why these are methods
at all and why there is a function len(str) but a method str.index(); one
could just as well have *either* str.length and str.index() *or*
length(str) and, say, a builtin

  locate( x, element, start = 0 , stop = None, reversed = False, default =  
Misfit )

(where Misfit indicates a 'meta-None', so None is still a valid default  
value;
i also like to indicate 'up to the end' with stop=None) that does on  
iterables
(or only on sequences) what the methods do now, but with this strange  
pattern:

------------------------------------------------------------------
         .index() .find() .get() .pop()
list       +               ?(3)   +
tuple                      ?(3)   ??(1)
str        +        +      ?(3)   ??(1)
dict       x(2)     x(2)   +      +

(1) one could argue this should return a copy of a tuple or str,
but doubtful. (2) index/find meaningless for dicts. (3) there
is no .get() for list, tuple, str, although it would make sense:
return the indexed element, or raise IndexError where not found
if no default return value given.
------------------------------------------------------------------

what bites me here is expecially that we have both index and find
for str *but a gaping hole* for tuples. assuming tuples are not slated
for removal, i suggest to move in a direction that makes things look
more like this:

------------------------------------------------------------------
         .index() .get() .pop()
list       +       +      +
tuple      +       +
str        +       +
dict               +      +
------------------------------------------------------------------

where .index() looks like locate, above:

------------------------------------------------------------------
{list,tuple,str}.index(
     element,            # element in the collection
     start = 0,          # where to start searching; default is zero
     stop = None,        # where to end; the default, None, indicates
                         # 'to the end'
     reversed = False,   # should we search from the back? *may* cause
                         # reversion of sequence, depending on impl.
     default = _Misfit,  # default value, when given, prevents
                         # IndexError from being raised
     )
------------------------------------------------------------------

hope i didn't miss out crucial points here.

_wolf



-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/