Moving to functional programming

[bruno.desthuilliers at gmail.com]

On 14 juil, 11:51, James Fassett <ja... at reggieband.com> wrote:
> On Jul 12, 12:18 am, George Sakkis <george.sak... at gmail.com> 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.