On 14 juil, 11:51, James Fassett <[EMAIL PROTECTED]> wrote: > On Jul 12, 12:18 am, George Sakkis <[EMAIL PROTECTED]> wrote: > > > It relies on positional arguments, tuple unpacking and > > the signature of zip(), > > It moreso relies on the fact that: > > >>> t1 = (0,1,2,3) > >>> t2 = (7,6,5,4) > >>> [t1, t2] == zip(*zip(t1, t2)) > > True > > This is mathematically true given the definition of zip. To me that is > very functional. Basically, unpacking a pair list into zip is the > canonical definition of unzipping the list (which is exactly my > intention). > > > Second, it is less readable, > > For a Python programmer - you are correct. For someone familiar with > the use of zip (as described above) - I wonder. Since I am new to this > I can't say for sure. If I posted the same code to a Haskell list or a > ML list would their opinion be the same?
You might find interesting than Python's list comprehensions were stolen from Haskell then !-) > > robust and efficient than the list comprehension. > > I don't know the internals of how the Python interpreter treats list > comprehensions According to a post on the pypy team's blog, mostly as sugar candy for the procedural version (IOW: the generated byte-code will be roughly equivalent). > and zip but it seems reasonable to assume an extra list > is created for the zip approach. > > However, in the limited functional code I have seen this is actually a > common practice. I would suppose in languages with lazy evaluation > this isn't a problem - but in Python it would be. Python has some kind of lazy evaluation too - look for yield, generator expressions, iterators, and the itertools package. -- http://mail.python.org/mailman/listinfo/python-list