[Python-ideas] An iterable version of find/index for strings?

[Brett Cannon]

FYI there is already a propposal for split:
http://bugs.python.org/issue17343. Getting that approved would help move
towards getting iterators for other relevant methods such as find and index.


On Thu, Apr 4, 2013 at 9:21 PM, Tom Schumm <phong at phong.org> wrote:

> Should Python strings (and byte arrays, and other iterables for that
> matter)
> have an iterator form of find/rfind (or index/rindex)? I've found myself
> wanting one on occasion, and having more iterable things seems to be the
> direction the language is moving.
>
> Currently, looping over the instances of a substring in a larger string is
> a
> bit awkward. You have to keep track of where you are, and you either have
> have
> to watch for the -1 sentinel value or catch the ValueError. A "for idx in
> ..."
> construction would just be cleaner. You could use re.finditer, but a string
> method seems a more lightweight/efficient/obvious.
>
> The best name I can think of would be "finditer()" like re.finditer().
> Using
> "ifind" (like izip) would be confusing, because it could be mistaken for
> case-
> insensitive find. I thought of "iterfind" like the old dict.iteritems, and
> ElementTree.iterfind but "iterrfind" (iterable rfind) is unattractive. I
> also
> think "find" is a more obvious verb than "index".
>
> I've got a simple Python implementation on gist:
> https://gist.github.com/fwiffo/5233377
>
> It includes an option to include overlapping instences, which may not be
> necessary (it's not present in e.g. re.finditer).
>
> I could imagine it as a method on str/unicode/bytes/list/tuple objects, or
> maybe as a function in itertools.
>
> --
> Tom Schumm
> http://www.fwiffo.com/
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130405/069be45d/attachment.html>