iterator support for SRE?
a common wish for SRE is a variant of findall that returns all match objects, instead of the strings. recently, I realized that the internal scanner type (originally added to speed up Python versions of findall/sub/split) can be wrapped in an iterator, allowing the user to loop over all matches.
how about adding a "finditer" method, which takes care of the low-level setup:
for match in p.finditer(somestring): print match.groups()
or should we just make the scanner factory an official part of the SRE interface? </F>
Or both? The scanner interface seems vaguely useful as a low-level tool to create other higher-level variants; but the finditer() call seems to nicely capture a common case. --Guido van Rossum (home page: http://www.python.org/~guido/)
guido wrote:
as you might have noticed, I went ahead and checked in code for "finditer". nobody has complained this far ;-) isn't "iterfind" a better name, btw? more like "iterkeys" (etc). if nobody complains, I'll change the name, and check in some documentation. ::: will have to think about scanner; I agree that it may seem to be vaguely useful, but cannot think of a use case that isn't better handled by findall/split/sub or iterfind. can anyone? </F>
as you might have noticed, I went ahead and checked in code for "finditer". nobody has complained this far ;-)
Far from it. :-)
Hm, but finditer() is more like findall(), and that counts more I'd say. --Guido van Rossum (home page: http://www.python.org/~guido/)
+1 on finditer. [/F]
It's in desperate need of usage docs. The few times I recall seeing it mentioned on c.l.py, it was from someone staring at the code unable to reverse-engineer its intended use. Therefore I don't believe it's gotten a good trial, and so I'm at best -0 on making it official now. In my own stuff I've built directly on top of .lastindex/.lastgroup instead -- perhaps only because it's easier to remember how to use your own undocumented stuff than somebody else's <wink>. the-folks-most-likely-to-use-a-framework-are-those-most-likely-to- write-their-own-ly y'rs - tim
Or both? The scanner interface seems vaguely useful as a low-level tool to create other higher-level variants; but the finditer() call seems to nicely capture a common case. --Guido van Rossum (home page: http://www.python.org/~guido/)
guido wrote:
as you might have noticed, I went ahead and checked in code for "finditer". nobody has complained this far ;-) isn't "iterfind" a better name, btw? more like "iterkeys" (etc). if nobody complains, I'll change the name, and check in some documentation. ::: will have to think about scanner; I agree that it may seem to be vaguely useful, but cannot think of a use case that isn't better handled by findall/split/sub or iterfind. can anyone? </F>
as you might have noticed, I went ahead and checked in code for "finditer". nobody has complained this far ;-)
Far from it. :-)
Hm, but finditer() is more like findall(), and that counts more I'd say. --Guido van Rossum (home page: http://www.python.org/~guido/)
+1 on finditer. [/F]
It's in desperate need of usage docs. The few times I recall seeing it mentioned on c.l.py, it was from someone staring at the code unable to reverse-engineer its intended use. Therefore I don't believe it's gotten a good trial, and so I'm at best -0 on making it official now. In my own stuff I've built directly on top of .lastindex/.lastgroup instead -- perhaps only because it's easier to remember how to use your own undocumented stuff than somebody else's <wink>. the-folks-most-likely-to-use-a-framework-are-those-most-likely-to- write-their-own-ly y'rs - tim
participants (4)
-
barry＠zope.com -
Fredrik Lundh -
Guido van Rossum -
Tim Peters