"Josiah Carlson" <jcarlson at uci.edu> wrote in message news:20070107095022.8D37.JCARLSON at uci.edu... > > "Christos Georgiou" <tzot at mediconsa.com> wrote: >> [snip] >> issue, but please understand this is not a question for help to change >> the >> algorithm (this has been done already), so it's not a question of c.l.py. >> It's a matter of discrepancy. > [snip] > > [snip Josiah's wordy "it's intentional and not a bug" in the form of a > suggestion > for a change of algorithm] Like I said, this wasn't a c.l.py question, even if you thought it deserved a c.l.py answer. In any case, you answered my question, and thank you. It not being a bug suits me just fine. Allow me to make sure we talk about the same thing here, though: both the example code I provided and the original one do modify the iterable *only* between the following A and B points in time: Point A: itertools.chain calls iter() on the iterable. (Appending to the iterable (list, deque) occur here, and only here.) Point B: itertools.chain starts calling iterable.next(). This is a different case from the one mentioned in the post by Raymond, and that is why I asked. For example, if itertools.chain called iter() on its arguments when actually needing to iterate over them instead of at the beginning, the code would work. But I really, really don't mind whatever the function, as long as it's by design, and that's the reason I didn't submit a bug in the tracker. That's all. I won't (and never intended) to defend any algorithms.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4