On Tue, 09 Dec 2014 21:44:54 -0500, Roy Smith wrote: > In article <54878f8a$0$13010$c3e8da3$54964...@news.astraweb.com>, > Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote: > >> I really think you guys are trying too hard to make this function seem >> more complicated than it is. If you find it so hard to understand a >> simple function with four short lines, one wonders how you would >> possibly cope with real code. > > Well, look at it this way. You've got several folks here (I count > Terry, Ned, Chris, and myself) all saying, "We find this confusing", and > you're saying, "nobody should find this confusing". I suppose one > possible explanation for this dichotomy is that we're all incapable of > dealing with real code. Yeah, that must be it.
I know you guys deal with *much* more complicated, obfuscated and difficult code. Just look at the stuff posted here by newbies :-) But you insist that you're confused by "while iters". I don't get it. I think you're protesting too much -- like the weightlifter who routinely bench- presses 400 lbs, but then insists he can't take the trash out because it's too heavy. Or you're insisting on an unrealistic ideal of "readable", that if it takes *any time at all* to think about the code, that makes it bad. I've noticed this deep-seated conservatism in Python programmers before. Parts of the language are deeply under-utilised, because there are simple idioms that people refuse to use because they're "confusing" even though they are a trivial generalisation of things that we use all the time. Or at least, they should be common idioms. They're not common idioms because nobody uses them, and nobody uses them because they're not common idioms. Example: In the statistics module in Python 3.4, I added a `median` function to calculate the median by the traditional schoolbook algorithm. But that's only one out of a number of ways to calculate medium, and inspired by similar syntax from R I proposed adding additional methods to that `median` object: median.low(alist) median.high(alist) etc. We all know that functions are first class objects with attributes and methods, they have a __dict__ so you can attach per-function data to them. And there's the last line of the Zen, about namespaces being awesome. Every instance with a __dict__ is a namespace. This ought to be a no-brainer, but apparently nobody has any experience with callable attributes attached to instances: math.sin(x) "some string".split(s) We make it a point of pride that functions in Python are not just first class values but that they are objects with attributes and methods and a per-instance __dict__. But when somebody proposes making use of that, it is rejected. Not that I'm bitter :-) But I digress. I'm truly sorry that I have been unable to express in words just how elegant and beautiful the short version of the myzip() function is. It is vanishingly rare to have such a perfect match between an algorithm and real working code. And if anyone has got the impression that I'm calling you a dummy because you don't see it my way, I'm not. I'm calling you nekulturny and somebody who can't recognise elegant code when it's staring you right in the face :-P -- Steven -- https://mail.python.org/mailman/listinfo/python-list