Aloha,
Thomas Lotze wrote:
>>A string, and a pointer on that string. If you give up the boundary
>>condition to tell backwards, you can start to eat up the string via f =
>>f[p:]. There was a performance difference with that, in fact it was faster
>>~4% on a python2.2.
> When I tried it just now, it was the other way around. Eating up the
> string was slower, which makes sense to me since it involves creating new
> string objects all the time.
I expected the f[p:] also to be slower, the 4% i only measured on one
platform. Most propably the CG and memory management isn't the same.
>>I dont't expect any iterator solution to be faster than that.
> It's not so much an issue of iterators, but handling Python objects
> for every char. Iterators would actually be quite helpful for searching: I
> wonder why there doesn't seem to be an str.iterfind or str.itersplit
> thing. And I wonder whether there shouldn't be str.findany and
> str.iterfindany, which takes a sequence as an argument and returns the
> next match on any element of it.
There is a finditer in the re. I'm currently rewriting a few pattern
matching things and find it quite valueable.
>>> import re
>>> pat = re.compile('[57]')
>>> f = "754356184756046104564"
>>> for a in pat.finditer(f):
... print a.start(),f[a.start()]
...
0 7
1 5
4 5
9 7
10 5
18 5
Wishing a happy day
LOBI
--
http://mail.python.org/mailman/listinfo/python-list
