Re: defining the behavior of zip(it, it) (WAS: Converting a flat list...)
> > ii. The other problem is easier to explain by example. > > Let it=iter([1,2,3,4]). > > What is the result of zip(*[it]*2)? > > The current answer is: [(1,2),(3,4)], > > but it is impossible to determine this from the docs, > > which would allow [(1,3),(2,4)] instead (or indeed > > other possibilities). > > """ > > IMO left->right is useful enough to warrant making it defined > > behaviour > > And in fact, it is defined behavior for itertools.izip() [1]. > > I don't see why it's such a big deal to make it defined behavior for > zip() too. IIRC, this was discussednd rejected in an SF bug report. It should not be a defined behavior for severals reasons: * It is not communicative to anyone reading the code that zip(it, it) is creating a sequence of the form (it0, it1), (it2, it3), . . . IOW, it conflicts with Python's style of plain-speaking. * It is too clever by far -- much more of a trick than a technique. * It is bug-prone -- zip(x,x) behaves differently when x is a sequence and when x is an iterator (because of restartability). Don't leave landmines for your code maintainers. * The design spirit of zip() and related functions is from the world of functional programming where a key virtue is avoidance of side-effects. Writing zip(it, it) is exploiting a side-effect of the implementation and its interaction with iterator inputs. The real spirit of zip() is having multiple sequences translated to grouped sequences out -- the order of application (and order of retrieving inputs) should be irrelevant. * Currently, a full understanding of zip() can be had by remembering that it maps zip(a, b) to (a0, b0), (a1, b1), . . . . That is simple to learn and easily remembered. In contrast, it introduces unnecessary complexity to tighten the definition to also include the order of application to cover the special case of zip being used for windowing. IOW, making this a defined behavior results in making the language harder to learn and remember. Overall, I think anyone using zip(it,it) is living in a state of sin, drawn to the tempations of one-liners and premature optimization. They are forsaking obvious code in favor of screwy special cases. The behavior has been left undefined for a reason. Raymond Hettinger -- http://mail.python.org/mailman/listinfo/python-list
Re: defining the behavior of zip(it, it) (WAS: Converting a flat list...)
[Steven Bethard] > >Then why document itertools.izip() as it is? The documentation there is > >explicit enough to know that izip(it, it) will work as intended. Should > >we make the documentation there less explicit to discourage people from > >using the izip(it, it) idiom? [Dave Hansen] > In any case, the solution seems obvious: if you want the guarantee, > use the tool that provides it. True enough :-) FWIW, the itertools documentation style was intended more as a learning device than as a specification. I combined regular documentation, approximately equivalent generator code, examples, and recipes. Hopefully, reading the module docs creates an understanding of what the tools do, how to use them, how to combine them, and how to roll your own to extend the toolset. Another goal was providing code fragments to support scripts needing to run on Py2.2 (itertools were introduced in Py2.3). Raymond -- http://mail.python.org/mailman/listinfo/python-list
Python as Guido Intended
[EMAIL PROTECTED] wrote: > it seems that quite some people > don't see the language as the creator or wants them to see it. Here's my two cents on this recurring theme. While nothing forces a particular programming style, there is some merit to swimming with the current rather than against it. Observing five years of newsgroup posts, I've observed that many who struggle with language or get angry about some part of it are fighting the language rather than using it as intended/designed. IMO, following designer intent leads to happiness because Guido's philosophies so thoroughly pervade the language. So, when you accept his viewpoints, you'll find that all the parts of the language tend to fit together neatly and easily. Conversely, fighting the language tends to result in one struggle after the next. For example, there is a person currently working on a new proposal for a container freezing protocol. In order to overcome all the fundamental difficulties (like what to do with mutable values when freezing a dictionary), the proponent is finding that he has to suggest pervasive changes to the language (including mutable strings, recursive freezing protocols, mutation notifications, etc). I suspect that he is fighting the language. It is not so much that his idea is wrong, it is just that he is effectively creating another language that is not Python. My own experience with adapting to Guido's design-view relates to tuples and lists. To Guido, tuples are for records and lists are for iteration. My own inclination is to view tuples as immutable lists. Accordingly, it seems obvious to me that tuples should have count() and index() methods for better substitutability. However, I've learned that adapting to Guido's world-view leads to happiness because Python's function signatures tend to reflect his design view. So, when I'm thinking the Guido way, my code comes together seamlessly. When I persist with a conflicting viewpoint, I find myself having to make conversions, write work-arounds, or create more helper functions than otherwise needed. Keep this in mind when finding yourself madder than heck about mylist.sort() returning None or zip(it,it) intentionally not documenting its implementation quirks. IMO, using the tools as given leads to easily-written, clean, maintainable, beautiful code. Learn to love what makes Python great. Pounding a square object into a round hole should be a cue that you're doing things the hard way ;-) respectfully submitted, Raymond -- http://mail.python.org/mailman/listinfo/python-list
Re: defining the behavior of zip(it, it) (WAS: Converting a flat list...)
> > FWIW, the itertools documentation style was intended more as a learning > > device than as a specification. I combined regular documentation, > > approximately equivalent generator code, examples, and recipes. > > Hopefully, reading the module docs creates an understanding of what the > > tools do, how to use them, how to combine them, and how to roll your > > own to extend the toolset. [Fredrik Lundh] > maybe it's time to change "equivalent to" to "similar to", to avoid > messing things up for people who reads the mostly informal library > reference as if it were an ISO specification. Will do. This is doubly a good idea because there are small differences in argument processing. For example, count() makes an immediate check for a numerical argument but the generator version won't recognize the fault until the count(x).next() is called. -- http://mail.python.org/mailman/listinfo/python-list
