[Tutor] PolyRange -- iterator
Hugo Arts
hugo.yoshi at gmail.com
Wed Nov 4 18:17:21 CET 2009
On Wed, Nov 4, 2009 at 5:38 PM, spir <denis.spir at free.fr> wrote:
> Hello,
>
> as I was crawling in endless complications with unadequate ranges, I decided to create a "PolyRange" type able to hold arbitrary many "sub-range"; which means finally a big range with wholes in it. This whole stuff again to cope with unicode -- a poly-range would be able to hold a range for a char class (eg 'letter') which spans over several ordinal ranges. (Viva unicode consortium!)
>
> So, it works as needed. It is even able to "stretch" over addictional sub-ranges or to "unite" with a poly-range brother (sister, too). See code below.
>
> Now, I need it to be properly iterable if needed -- the main use beeing indeed the 'in' operator -- but who knows. So, I tried to implement __iter__ and next (by the way, why isin't it called __next__ instead, looks strange for a python builtin?). Seems to work, but the result looks veeery heavy to my eyes. As I had never written an iterator before, would be nice and criticize the code?
>
You're right, next() should really be called __next__(), and this is
actually fixed in python 3 (don't know why it wasn't originally done
this way).
Now, the code. If you write __iter__ as a generator, you won't have to
write a next method at all. It simplifies The thing a whole lot:
def __iter__(self):
for range in self.ranges:
for item in range:
yield item
That's it. Alternatively, you could turn the whole thing into a
one-liner and just return a generator expression from __iter__:
def __iter__(self):
return (item for r in self.ranges for item in r)
It's not as clear though, and it doesn't save that much space. I like
the first one slightly better.
python documentation on generators:
http://docs.python.org/tutorial/classes.html#generators
Hugo
More information about the Tutor
mailing list