RetroSearch Browse

Sun May 20 07:36:10 CEST 2007 · https://mail.python.org/pipermail/python-dev/2007-May/073250.html

>> I'd rather see iterator versions of the set operations. 
> 
> Interesting idea.  I'm not sure I see how to make it work.
> If s|t returned an iterator, then how would s|t|u work?

I don't think s.union(t) should return an iterator, if for
no other reason than compatibility. Instead, there might
be s.iunion(t) (or s.unioni(t), or s.iterating_union(t)).

Then, you could spell s.iunion(t.iunion(u)). iunion is
implemented as

def iunion(self, other):
  for o in self:
    yield o
  for o in other:
    if o not in self:
      yield o

So rather than writing

  x = a.union(b,c,d,e)

you could write

  x = set(a.iunion(b.iunion(c.iunion(d.iunion(e)))))

or

  x = a.union(b.iunion(c.iunion(d.iunion(e))))

Likewise

def iintersection(self, other):
  for o in other:
    if o in self:
      yield o

> Are you proposing lazy evaluation of unions, intersections,
> and differences?

I'm not so sure about differences: union and intersections
are commutative, so one should typically be able to reorder
the evaluation so that the left operand is a true set,
and the other is the iterator. For difference, it would
be necessary that the right operand is the true set;
it couldn't be an iterator, as you need to test whether
an element of self is in the other operand.

Regards,
Martin

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2007-May/073250.html below:

[Python-Dev] Py2.6 buildouts to the set API