Guido on the history of Python [LWN.net]

Python creator Guido van Rossum has been writing a series on the history of the language; the latest installment is titled From List Comprehensions to Generator Expressions". "Why the differences, and why the changes to a more restrictive list comprehension in Python 3? The factors affecting the design were backwards compatibility, avoiding ambiguity, the desire for equivalence, and evolution of the language. Originally, Python (before it even had a version :-) only had the explicit for-loop. There is no ambiguity here for the part that comes after 'in': it is always followed by a colon. Therefore, I figured that if you wanted to loop over a bunch of known values, you shouldn't be bothered with having to put parentheses around them."

(Log in to post comments)

Guido on the history of Python

Posted Jul 2, 2010 4:33 UTC (Fri) by rsidd (subscriber, #2582) [Link]

I use Python, but in many cases it is just plain inelegant. The example of the variable in a list comprehension "leaking" has bitten me (it took me half an hour to figure out what was going on). I'm glad that's fixed in Python 3. Another annoyance is that there is no function that takes a list (or other sequence) and returns the reversed list. There is a reverse() method for lists, but it sorts the list in-place and has no return value. Likewise the sort() method for sequences. There is a "sorted" function whose input is polymorphic, but it always returns a list even when the input is a string or some other type.

So if I want to return the "reverse complement" of a string where the "complement" function is defined, without destroying the original string, I will need to do something like

sr = s
sr.reverse()
complement(sr)

where in Haskell I could just do (with no side-effects)

complement (reverse s)

So while python borrows a lot of nice ideas from functional programming, it makes it hard to actually program in a functional style.

Guido on the history of Python

Posted Jul 2, 2010 7:23 UTC (Fri) by jbh (subscriber, #494) [Link]

You may be looking for reversed()?
>>> complement(reversed(s))

But yes, neither reversed() or sorted() preserve the input type. If complement expects a string rather than an iterable, you'd have to construct the string yourself, something like
>>> complement(''.join(reversed(s)))

(fwiw, the input to sorted() and reversed() isn't strictly speaking polymorphic, it's an iterable)