Archive for the 'python' Category

The first bug I got back from Beta 2 showed that the new Crash Reporter functionality wasn’t always started up correctly… despite my testing for that case. Turns out that what I thought was memory given to me by Python was in fact garbage collected (and therefore … disappears after an indeterminate amount of time). Since the Crash Reporter is the means for users to signal bugs, I’ve had to rush the third beta.

Python 3000 will remove maps and folds. (Python names: map & reduce). I believe this is a mistake.

Fold and map state the nature of the data-dependencies in a segment of code: the way data flows through that code. It is the fact that they limit the data-dependencies that is useful. When I see reduce(lambda x,y: x|y, ss, set()) I know that the sets will all be ored together. When I read a for loop doing the same thing I have to be much more careful, as a for loop does not limit the way in which data flows though it: it has a much higher data-dependency degree of freedom.

Examples don’t really capture this, because it has more to do with the mind of the beholder than the actual mechanics. Nevertheless the difference is real, and has real implications for distributing processing, as this paper from google shows. (via joel).

Indeed the use of maps and folds in Python is limited by other factors. I use maps and folds much more in Haskell, because Haskell efficiently supports functional composition: