On 2017-06-28 09:16, Steven D'Aprano wrote:
On Tue, Jun 27, 2017 at 01:53:37PM -0700, Mike Miller wrote:
>
>On 2017-06-25 20:23, Steven D'Aprano wrote:
> >I have a counter-proposal: introduce the iterator chaining operator "&":
> >
> > iterable & iterable --> itertools.chain(iterable, iterable)
> >
>
>I like this suggestion. Here's another color that might be less
>controversial:
>
> iterable3 = iterable1.chain(iterable2)
That requires every iterable class to add its own reimplementation of
chain, or else it will surprisingly not be chainable -- or at least it
*sometimes* won't be chainable.
chain(iterable1, iterable2) would be more acceptable. The reason why a
function would be better here than a method is explained in the FAQ for
why len() is a function.
I still think a good middle ground would be to have such a function,
but have the return type of that function be an iterator that provides a
.chain method or (better) defines __add__ to allow adding it to other
iterables. Then a single call to "chain" (or whatever the global
function was called) would be enough to give you a nice readable syntax
if you later want to chain other iterables on. This behavior would not
need to be stipulated for any other kinds of iterators; "chain" would
just be a function that converts any iterable into a nicely chainable
one, similar to how pathlib.Path converts a string into a nicely
manipulable Path object that allows various handy path operations.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
