On Tue, Jun 27, 2017 at 12:12 AM, Steven D'Aprano <st...@pearwood.info>
wrote:
> > > I have a counter-proposal: introduce the iterator chaining operator
> "&":
> > > iterable & iterable --> itertools.chain(iterable, iterable)
> >
> > In [1]: import numpy as np
> > In [2]: import itertools
> > In [3]: a, b = np.array([1,2,3]), np.array([4,5,6])
> > In [4]: a & b
> > Out[4]: array([0, 0, 2])
> > In [5]: a + b
> > Out[5]: array([5, 7, 9])
> > In [6]: list(itertools.chain(a, b))
> > Out[6]: [1, 2, 3, 4, 5, 6]
> >
> > These are all distinct, useful, and well-defined behaviors.
>
> - keep the existing __and__ and __rand__ behaviour;
> - if they are not defined, and both operands x, y are iterable,
> return chain(x, y);
>
I understand. But it invites confusion about just what the `&` operator
will do for a given iterable. For NumPy itself, you don't really want to
spell `chain(a, b)` so much. But you CAN, they are iterables. The
idiomatic way is:
>>> np.concat((a,b))
array([1, 2, 3, 4, 5, 6])
However, for "any old iterable" it feels very strange to need to inspect
the .__and__() and .__rand__ () methods of the things on both sides before
you know WHAT operator it is.
Maybe if you are confident a and b are exactly NumPy arrays it is obvious,
but what about:
from some_array_library import a
from other_array_library import b
What do you think `a & b` will do under your proposal? Yes, I understand
it's deterministic... but it's far from *obvious*. This isn't even doing
something pathological like defining both `.__iter__()` and `.__and__()` on
the same class... which honestly, isn't even all that pathological; I can
imagine real-world use cases.
I think that chaining iterators is common enough and important enough in
> Python 3 to deserve an operator. While lists are still important, a lot
> of things which were lists are now lazily generated iterators, and we
> often need to concatenate them. itertools.chain() is less convenient
> than it should be.
>
I actually completely agree! I just wish I could think of a good character
that doesn't have some very different meaning in other well-known contexts
(even among iterables).
Some straw men:
both = a ⊕ b
both = a ⇢ b
Either of those look pretty nice to me, but neither is easy to enter on
most keyboards.
I think I wouldn't mind `&` if it only worked on iteraTORS. But then it
loses many of the use cases. I'd like this, after all:
for i in range(10)⇢[20,19,18]⇢itertools.count(100):
if i>N: break
...
--
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons. Intellectual property is
to the 21st century what the slave trade was to the 16th.
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
