On Thu, Nov 16, 2017 at 07:56:21AM -0600, bunslow wrote about the roundrobin recipe in the itertools docs:
> However, it is remarkably unpythonic, in my opinion [...] > Things that strike me as unpythonic: 1) requiring the total number of input > iterables 2) making gratuitous use of `next`, 3) using a while loop in code > dealing with iterables, 4) combining loops, exceptions, and composed > itertools functions in non-obvious ways that make control flow difficult to > determine I don't find *any* of those things unPythonic in the least, nor the recipe difficult to follow. > Now, I get it, looking at the "roughly equivalent to" code for zip_longest > in the docs, there doesn't seem to be much way around it for generally > similar goals, and as I said above, unpythonic is fine when necessary > (practicality beats purity), but in this case, for being a "recipe" in the > itertools docs, it should *make use* of the zip_longest The roundrobin recipe was introduced to the docs some time during Python 2.5. zip_longest (or izip_longest as it was originally called) wasn't introduced until 2.6. [...] > Instead, the following recipe (which I also submitted to the StackOverflow > question, and which is generally similar to several other later answers, > all remarking that they believe it's more pythonic) is much cleaner and > more suited to demonstrating the power of itertools to new developers than > the mess of a "recipe" pasted above. A "mess" of a quote-unquote "recipe". That's an insulting way of describing it. I'd like to see how you would have solved this problem back in Python 2.5. Your post is a very long-winded way of saying: "I have an improved, more modern implementation for the itertools roundrobin recipe, should I raise a documentation issue on the tracker to replace it?" to which I would say, "Sure, why not?". > I realize at the end of the day this is a pretty trivial and ultimately > meaningless nit to pick, but I've never contributed before and have a > variety of similar minor pain points in the docs/stdlib, and I'm trying to > gauge 1) how well this sort of minor QoL improvement is wanted, and 2) even > if it is wanted, am I going about it the right way. 1) is fine. 2) is not. You don't need to put down existing code to make your point, nor do you have to sing your code's praises. Let the code speak for itself. And while its one thing to write detailed and pedantic posts (I have a tendency to do likewise) know when its necessary and when it isn't. Sometimes we need to discuss a lot of background material to explain something, but this wasn't one of those times. Thank you, -- Steve _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
