July 2006


functional 0.7.0 has been released to PyPI and to the project’s own website. Included in this release:

  • Several reference counting-related bugs were squashed.

  • The C implementation now supports Python 2.3, in addition to 2.4 and 2.5.

  • The test suite has been enhanced with fine-grained checking for reference counting bugs to try to keep the C version correct.

  • Two new functions were added, map() and filter(), which function much like the Python built-ins of the same name — but without some of the built-ins’ weird behaviour.

Lastly, I know I said before that functional would include a functional.bwcompat submodule that contained exact copies of some Python builtins, the aim being to ease the transition to Python 3.0 for larger projects (when map() and filter() will no longer ship). I changed my mind for two reasons: 1) converting map() and filter() calls to list comprehensions will be part of a larger Python 2.x -> Python 3.x conversion, and 2) the more I waded in, the more I realised that Python’s built-ins have some really twisted semantics. So, instead of duplicating the builtins, I opted to write sane versions of these functions, which can be found at functional.map() and functional.filter().

Python Eggs of both versions, for Python 2.3 - 2.5, as well as tarballs, are available from PyPI.

From Foreign Policy:

India’s education ministry has decided to opt out of an MIT-inspired initiative to provide $100 laptops to school children across the developing world. Calling the plan “pedagogically suspect”, India’s Ministry of Human Resources Development determined that its money could be better spent on badly needed classrooms and teachers.

Good for India. Every time I see a Slashdot story about MIT Media Lab’s $100 laptop project, I cringe. The project’s director, Nicholas Negroponte, however, clearly believes the world is in such peachy shape that laptops for the developing world are the best use of this time and money.

The first sign that this was a bad idea should have been the design requirement that the laptop feature a crank to charge the battery. Why? Because the laptop is intended to be sent to places where there’s no electricity. Now, I would conclude that perhaps what these people need is electricity and other basic infrastructure. That’s not sexy, though, the sort of thing must be too mundane for MIT’s geniuses to spend their valuable time on.

In this Wired article, one of the laptop’s designers, Yves Béhar, answers such criticism:

Béhar thinks the laptop project is more pragmatic than his skeptics realize. “There’s a criticism that comes up,� he says. “I think it’s the stupidest argument: Send kids food, send them water.� These critics, he says, imagine all the developing world to be a famine-stricken village in Africa. “This is the typical ignorance of the West. There are different conditions in different places,� he says. “And there are a lot of places where kids are not starving, where kids want to learn more than anything else.�

Really? Let’s see what India’s Education Secretary said

We need classrooms and teachers more urgently than fancy tools.

This is the typical ignorance of the Ivory Tower’s IT department, that what these kids really need is technology — in this case, a laptop. Let’s for a moment apply the same solution to the United States: is the solution to the problems with America’s education system to give each student a laptop? Will that make up for cronic underfunding? Will that hire better teachers? The Indians would rather spend the laptop money on making secondary education universal. That sounds like a real solution to a real problem.

I realise that fixing imaginary problems — like the lack of laptops — is a lot sexier than figuring out how to provide clean water and highways to Africa. I just keep hoping that someday, someone at MIT will wake up and pull the plug on this misguided techno-utopian farce.

As I mentioned in the last post, I’ve recently added reduce(), map() and filter() to functional. Since these mimic the semantics of the original Python built-ins, and since I wanted a sane version of map() at the same time, I decided to move reduce() and co. into a separate backwards compatibility-focused submodule, functional.bwcompat.

Now, this wasn’t a problem for the pure Python version of functional — you just add a new bwcompat.py in the functional/ directory. However, the C version turned out to be a bit trickier.

Most extension modules are just that — modules — meaning that there’s a foomodule.c file that creates an importable foo module. There’s little, if any, intentional support for creating packages at the C level. The popular way, as some googling turned up, is to create the root module, then manually add the submodules using PyModule_AddObject(). This works, but it means that all your submodules are imported as soon as you import the root namespace. It’s not a big deal, but it’s not ideal, either (for more background, see this python-dev thread.).

If you find yourself in the same situation, initfunctional() in functionalmodule.c should make a pretty good guide. A more stripped-down version can be found in this python-list post from Alex Martelli

.