itertools.chain should take an iterable ?
Working on a tree library I've found myself writing itertools.chain(*[child.method() for child in self]). Well this happened after I tried instinctively itertools.chain(child.method() for child in self). Is there a reason for this signature ? Regards paolino
On Thu, Sep 01, 2005 at 07:58:40PM +0200, Paolino wrote:
Working on a tree library I've found myself writing itertools.chain(*[child.method() for child in self]). Well this happened after I tried instinctively itertools.chain(child.method() for child in self).
Is there a reason for this signature ?
This is more suited to comp.lang.python Consider the below examples (and remember that strings are iterable)
import itertools as it list(it.chain('ABC', 'XYZ')) ['A', 'B', 'C', 'X', 'Y', 'Z'] list(it.chain(['ABC', 'XYZ'])) ['ABC', 'XYZ'] list(it.chain(['ABC'], ['XYZ'])) ['ABC', 'XYZ']
Hope that helps, -jackdied
Jack Diederich wrote:
On Thu, Sep 01, 2005 at 07:58:40PM +0200, Paolino wrote:
Working on a tree library I've found myself writing itertools.chain(*[child.method() for child in self]). Well this happened after I tried instinctively itertools.chain(child.method() for child in self).
Is there a reason for this signature ?
This is more suited to comp.lang.python
Why ? I'm not asking for help ,I'm asking why itertools library is implemented like that and if it is possible to clean it.
Consider the below examples (and remember that strings are iterable)
import itertools as it list(it.chain('ABC', 'XYZ'))
['A', 'B', 'C', 'X', 'Y', 'Z']
list(it.chain(['ABC', 'XYZ']))
['ABC', 'XYZ']
list(it.chain(['ABC'], ['XYZ']))
['ABC', 'XYZ']
What if I want to chain an infinite list of iterables? Shouldn't itertools.chain be built to handle that? I don't think it is a problem to accept only the second case you paste and produce TypeError on the others. Hope this explains and to get other reasons. Regards Paolino
Hope that helps,
-jackdied _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/paolo_veronelli%40libero.i...
[Paolino]
Well this happened after I tried instinctively itertools.chain(child.method() for child in self).
As Jack's note points out, your proposed signature is incompatible with the one we have now. I recommend creating your own version: def paolino_chain(iterables): for it in iterables: for element in it: yield element >>> list(chain(c+c for c in string.ascii_uppercase)) ['A', 'A', 'B', 'B', 'C', 'C', 'D', 'D', 'E', 'E', 'F', 'F', 'G', 'G', 'H', 'H', 'I', 'I', 'J', 'J', 'K', 'K', 'L', 'L', 'M', 'M', 'N', 'N', 'O', 'O', 'P', 'P', 'Q', 'Q', 'R', 'R', 'S', 'S', 'T', 'T', 'U', 'U', 'V', 'V', 'W', 'W', 'X', 'X', 'Y', 'Y', 'Z', 'Z']
Is there a reason for this signature ?
It was handy for the use cases I had in mind when creating the function. Also it was styled after a version in another language where it had proven successful.
This is more suited to comp.lang.python
Why ? I'm not asking for help ,I'm asking why itertools library is implemented like that and if it is possible to clean it.
The newsgroup would have guided you to the solution listed above. If you want to request a new feature, please use SourceForge. Raymond
"Paolino" <paolo_veronelli@libero.it> wrote in message news:431842AA.2050405@libero.it...
What if I want to chain an infinite list of iterables? Shouldn't itertools.chain be built to handle that?
Raymond already suggested a four-line function that does exactly that. Create your own personal-library modules containing the functions you find useful as building blocks, and when you have a large sw base using them, present your building blocks along with their use cases as arguments for inclusion in the standard library.
I don't think it is a problem to accept only the second case you paste and produce TypeError on the others.
It would break compatibility with the current uses of itertools.chain . I like it (and have used it) as it is.
Christos Georgiou wrote:
"Paolino" <paolo_veronelli@libero.it> wrote in message news:431842AA.2050405@libero.it...
What if I want to chain an infinite list of iterables? Shouldn't itertools.chain be built to handle that?
Raymond already suggested a four-line function that does exactly that.
Create your own personal-library modules containing the functions you find useful as building blocks, and when you have a large sw base using them, present your building blocks along with their use cases as arguments for inclusion in the standard library.
I don't think it is a problem to accept only the second case you paste and produce TypeError on the others.
It would break compatibility with the current uses of itertools.chain . I like it (and have used it) as it is.
I see ,I just thought itertools was young and important enough to be investigated and eventually changed, but probably this is not the place to talk about that.I will submit the feature request to SF. I must add that the inverse story would have been def handy_chain(*args): return itertools.chain(iter(args)) a two-line function (ex lambda). Generally speaking, having a star-signature in a base library function is not a good choice. This is a proof of a case. Thanks all and have a nice summer.
participants (4)
-
Christos Georgiou -
Jack Diederich -
Paolino -
Raymond Hettinger