On Wed, Nov 4, 2009 at 5:38 PM, spir <denis.s...@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
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
