This episode is about streams, a typical data structure of functional languages. The differences between functional streams and imperative iterators are discussed. En passant, I give a solution of the classic eight queens problem.

This episodes explains how to implement a functional list comprehension syntax in Scheme. The difference with Python list comprehension is also explained. Moreover, I have decided to distribute the code create for this series as a library: http://www.phyast.pitt.edu/~micheles/scheme/aps.zip

I am republishing an old article I wrote in 2005 for O' Reilly (see http://www.onlamp.com/pub/a/python/2005/11/03/twill.html). The article is slightly outdated, but not much, and I am republishing it since nowadays to criticize excessive unit testing has become fashionable.

The third edition of the Italian Python Conference is coming. This year we have Guido van Rossum as guest of honor! The place is Florence, the dates are 8-9-10 of May, the website is http://www.pycon.it, what are you waiting for? You cannot miss it!

This episode is a direct continuation of latest issue: it gives example of use of the destructuring bind form let+ introduced there. I also discuss multiple values, unary functions and functions with optional arguments.

In my Adventures I have referred many times to pattern matching, but only in the context of compile time pattern matching in macros. There is another form of pattern matching, which is quite common in Scheme and in other functional languages: run time pattern matching. This episode will shed some light on the technique.

Everything you ever wanted to know about currying, partial application, higher order functions and related topics.

The first installment of my long-awaited third cycle of a Pythonista's adventures with Scheme is devoted to Scheme's functional aspects.

You may be interested in this post if you have an obsolete computer you don't want to throw away. The recipe to recover it is to install a lightweight window manager: you will see that your old box come back to new life.

I have argued many times that multiple inheritance is bad. Is it possible to set it straight without loosing too much espressive power? My strait module is a proof of concept that it is indeed possible. Read and wonder ...

In this post I clarify my position with respect to mixins, I show a few common design mistakes and I suggest some alternative solution.

Some update about my experiences with the EeePC.

A mixin is a collection of methods that can be injected into a class. The mixin technique consists in building classes by composing reusable mixins. The advantages and disadvantages of the technique are very much debated. I will focus on the negative aspects.

After a few weeks of work, version 3 of the decorator module is finally out. The new version is a major rewrite of the original implementation, lots of things have been improved under the hood, and the documentation has had a major overhaul too. The module is hosted on the PyPI site: http://pypi.python.org/pypi/decorator.

I am asking the users of my decorator module if they would accept a new version breaking backward compatibility in a minor way.