## Python 2.5a1 released

Python 2.5 seems to be feature complete now and is released as a first alpha. See here for a complete list of new features.

From a language perspective enhanced generators and the new with-statement are probably the most interesting features. For many developers the incorporation of the small relational database sqlite, the new XML package elementree and the foreign function interface ctypes might be the highlights.

## Comment viewing options

### FP support in Python

I also thought it was interesting that they added things explicitly for FP: "The functional module is intended to contain tools for functional-style programming.".

Currently all it does is curry functions.

### yeah, espesially as GvR's

yeah, espesially as GvR's attitude so far seems to have been that functional programing is not in the style of python, and should be avoided. With the proposed removal of lambda and so on. Is this a change in policy? Will they make functional programing in Python reasonable? do we get tail call optimisations?

### Way of appeasing the FP advocates

I see this as a way of quelling the FP advocates' criticisms of Python. No language changes, just a module with some FP tools in it. I don't expect to see language-level changes, like tail call optimization.

### TCO

Depressingly, TCO is just as much an OO thing as it is an FP thing, at least at the technical level (of course, culturally...)

### So True

Felleisen talks about this in section 3 (starts at page 51)
of this presentation.

### I don't really think thats accurate

The proposed removal of lambda, map, filter etc weren't due to any rejection of FP concepts - they were because they were either ugly (lambda), or redundant with the addition of list and generator comprehensions (Note that all that was proposed for map / filter / reduce was taking them out of the default namespace - there is nothing requiring them there rather than in a seperate module a la functional.

Most of pythons recent features seem to be moving in a more functional direction - not less. Since 2.0 we've had nested scopes, List comprehensions borrowed from haskell, lazy sequences via generators and various other minor additions (like partial)

### GvR at ACCU-USA last night

At last night's ACCU (Silicon Valley) meeting, Guido gave a talk about Python 3000. It was a warmup for his keynote speech to be given at the ACCU's annual conference, which will be held in Oxford in about two weeks.

(Python 3000 aka Python 3.0 or Py3k is the nickname for the version that is finally "allowed" to break backwards compatibility, and fix a number of inconsistencies, though it won't be a wholesale language redesign. See the Py3k PEP for details.)

To address your specific concerns, Li: (As far as I understand the Py3k plans ...) Python will not become a functional programming language. A standard requiring TCO implementation is unlikely. Lambda will neither be removed, nor will it be likely to be extended to allow multiple statements. List comprehensions will likely become syntactic sugar for a list view of a generator expression. Several of the builtins that currently work with or return lists will be changed to return either iterators or views.

IMHO, the last two points combine to permit a few slightly more FP-like programming idioms than are currently common in Python.

### if-else

I'm inclined to believe the conditional expression syntax was designed to discourage use. Yuck.

### Minor band aid.

Well, naturally you could just use a function:

def iif(condition, trueAnswer, falseAnswer):
if (condition):
return trueAnswer
else:
return falseAnswer

logging = 1

level = iif(logging, 1, 0)

But then that means that both the true and false branches have to be eagerly evaluated. Perhaps a lazy evaluation of function parameters is in order? Nah, too much like FP.

### Can be done lazily with lambda

Can be done lazily with lambda:

def iif(cond, true, false):
if cond:
return true()
else:
return false()

logging = 1

level = iif(logging, lambda:1, lambda:0)


### lazy eval

I think the issue here with lazy evaluation is that it is not locally understandable. That is, you'd have to know what kind of function iff was before you could tell if the expressions would always be evaluated or not. That's a pretty major semantic change based on a dynamic lookup of the "iff" variable.

With a dynamic environment you don't want to yank the programmer's legs out from under him by introducing things like this; at least you can understand a function call without understanding anything about the other end. But with lazy evaluation you'll lose that.

### Side effects?

It would seem to me that if the lambda expressions eschew side effects then lazy evaluation should be equivalent to eager evaluation. So, it isn't really lazy evaluation that causes you to lose understanding of a function's behavior, it's the existence of side effects. Right?

### Except in cases of where there's a stream...

...either the stream has no contents. Or perhaps an infinite recursion. Or maybe you just don't want the performance hit.

Most typical case that I constantly encounter is null objects.

string x = (obj == null)? "" : obj.ToString();

Anyhow, you have a case here where the true or false branch may be invalid if eagerly evaluated. That's probably the more immediate concern in this particular evaluation construct.

### side effects

Well, computational effort is a side effect of a sort, as is halting, and lazy evaluation has substantial effects on both of those. And there's no way to statically determine if side effects exist in a hybrid language like Python. But sure, if Python was a different language, lazy evaluation might work just fine ;)

Personally, though, my programs are primarily motivated by the existance of side effects. If it wasn't for side effects, I could just *imagine* I had created a working algorithm, without bother to run it.

### More interesting news from GvR

He is planning to add generic functions to Python3000.

### Details please

What kind of genericity are we talking about? Any links?

(I checked, and it's April 10th already, so I guess this isn't an April Fool's joke...)

### Guido's Artima Weblog

Guido van Rossum's Weblog

Python 3000 - Adaptation or Generic Functions?

Dynamic Function Overloading

I'm going to stick to the term "(dynamically, or run-time) overloaded functions" for now, despite criticism of this term; the alternatives "generic functions", "multi-methods" and "dispatch" have been (rightly) criticized as well.