Bug in string.find; was: Re: Proposed PEP: New style indexing,was Re: Bug in slice type

[Antoon Pardon]

Op 2005-08-29, Steven Bethard schreef <steven.bethard at gmail.com>:
> Antoon Pardon wrote:
>> I think a properly implented find is better than an index.
>
> See the current thread in python-dev[1], which proposes a new method, 
> str.partition().  I believe that Raymond Hettinger has shown that almost 
> all uses of str.find() can be more clearly be represented with his 
> proposed function.

Do we really need this? As far as I understand most of this
functionality is already provided by str.split and str.rsplit

I think adding an optional third parameter 'full=False' to these
methods, would be all that is usefull here. If full was set
to True, split and rsplit would enforce that a list with
maxsplit + 1 elements was returned, filling up the list with
None's if necessary.


  head, sep, tail = str.partion(sep)

would then almost be equivallent to

  head, tail = str.find(sep, 1, True)


Code like the following:

         head, found, tail = result.partition(' ')
         if not found:
             break
         result = head + tail


Could be replaced by:

         head, tail = result.split(' ', 1, full = True)
         if tail is None
             break
         result = head + tail


I also think that code like this:

          while tail:
              head, _, tail = tail.partition('.')
              mname = "%s.%s" % (m.__name__, head)
              m = self.import_it(head, mname, m)
	      ...


Would probably better be written as follows:

	  for head in tail.split('.'):
	      mname = "%s.%s" % (m.__name__, head)
	      m = self.import_it(head, mname, m)
	      ...


Unless I'm missing something.


-- 
Antoon Pardon


[1]http://mail.python.org/pipermail/python-dev/2005-August/055781.html