5 ms·
This is in the zip documentation as the way of solving this problem. Sort of surprised the author didn't look up the documentation before writing what is otherw
by hartror 13y ago
This is in the zip documentation as the way of solving this problem. Sort of surprised the author didn't look up the documentation before writing what is otherwise a very good post.
The left-to-right evaluation order of the iterables is guaranteed. This makes
possible an idiom for clustering a data series into n-length groups using
zip(*[iter(s)]*n).
http://docs.python.org/2/library/functions.html#zip http://docs.python.org/2/library/functions.html#zip
- StavrosK 13y agoI am also surprised I didn't look it up. I guess that I didn't expect that anything more than how zip() works would be there, and I already knew that. I've updated the post with this, another commenter pointed it out. Thanks!
- akavel 13y agoBy the way, I was recently surprised by a similar pattern in linux, where you can do: (echo -e "one\ntwo\nthree\nfour") | paste -d, - - to get result of: one,two three,four by exploiting a similar trick, i.e. reading two times ('- -') from the same iterator (STDIN of 'paste')
- apw 13y agoThanks for posting this. For reference, paste is a standard UNIX utility, whose purpose is to do all sorts of useful things not limited to 2-tuples: $ seq 1 9 | paste - - - 1 2 3 4 5 6 7 8 9
- tambourine_man 13y agoNo need for parentheses, echo -e "one\ntwo\nthree\nfour" | paste -d, - - works just fine
- impressive 13y agoRecently I was downvoted 2-3 times on S.O. for an answer that was claimed to be non-idiomatic. So, I cleaned it up, but it really irked me. What I had written was totally fine. It shouldn't have hurt anyone's eyes. It was direct. It was in-your-face. It was not magic. Reading this post brought back that feeling. If people don't understand a completely valid and terse way of coding something, sometimes instead of bothering to understand it, they will bash it. Sometimes, this is a totally valid way to vent frustration, and then they learn something new, and all is good. But sometimes, it just gets left as "this is wrong" and then someone else thinks it is wrong, and so on. That is wrong, and tech leads or architects that enforce such crap will bug the living shit out of good developers and lose them. I appreciate clarity. But, terse one-liners can be just as clear if not clearer than code that unnecessarily adds more methods/functions/names/local vars and claims to be "more testable", etc. You shouldn't have to sacrifice the ability to be terse and clear at the same time. Testing is no excuse for code bloat. You can likely write a test that executes the behavior without having to atomize it. Assess the amount of production and test code you are writing. How much more code are you actually having to write in order to test, both in the tests themselves and in the code which you are having to test? It happened here with Python and it happens in many languages. It even happens with laws and regulations in government. If someone gets the same thing done just as ethically but without the bureaucracy, just appreciate it as another perhaps better way of doing something. Don't bash it publically because you don't understand it.
- chipsy 13y agoI think the mentality can be extended to most code-reading. Don't get it by skimming? Must be crap code. I only got away from that when I changed my litmus test towards whether I could write on top of the codebase successfully, not how it looked. Today my only real point of judgment about the look of code is whether it's written in a style that increases average error rate. w/r to Python in particular, it has a history of ending up with idioms that are "tricky" and not particularly more or less terse than other techniques, but are able to exploit the standard library functions to get a faster-running result. This is, of course, at odds with the motto of "there should be only one (obvious) way to do it," so every experienced Python programmer has to internalize a small dictionary of idiomatic one-liners for these exceptional cases. (Fortunately, it's not that big. I can only think of three or four off the top of my head.)
- specialist 13y agostyle that increases average error rate Errors per LOC is allegedly constant, across all languages. I also consider the cost of change when designing things. I once created an HL7 wrapper that was a marvelous thing of beauty. Fluent API, clever use of the type system. But no one could maintain it, including me. It had too much magic. So I scrapped it, went with a dumber implementation.
- aidenn0 13y ago> Errors per LOC is allegedly constant, across all languages. If this is true, then a more verbose style will have a higher error rate. (more LOC to do the same task -> more errors)
- adventureloop 13y ago> Errors per LOC is allegedly constant, across all languages. This implies that more expressive languages(more expressions per line) are less prone to errors. You conclusion would be correct if he had stated that error per expression was constant between languages.
- norswap 13y agoKind of ironic for a language whose motto is "explicit is better".
- StavrosK 13y agoIt does say "possible", not "recommended" or even "sane"...
- catwell 13y agoThe fact that this idiom is documented in the official Python documentation makes me cringe, knowing that this code is not what I would call explicit. This is one of those cases where Ruby does it better (s.each_slice(3).to_a).