brainwagon

As a public service, I thought that this might be of interest: a Python program to load your iPod Shuffle.

The Lonely Lion has a small snippet of Python that adds files to iTunes using the COM interface. Could be useful.

While playing around with Flickr, I did a quick grovel through their services API. It appears that James Clarke has already written a Python binding.

Over at random thoughts, they’ve got a nice quickie: Python code to talk to a jabber server.

pydot is an interface to the GraphViz suite of programs for drawing abstract graphs and networks. Nifty. I’ve had need of such a thing quite a few times, and it only took me about two minutes to convert a part of my home directory hierarchy into the picture on the right. Fun stuff.

Not that impressed? How ’bout this slightly nicer diagram of the history of Unix variants? Pretty cool.

My ipod is on the fritz, so this isn’t immediately useful to me, but check out pypod: a Python library and script for manipulating the song database on your ipod. Neat. When mine comes back from the shop, I’ll have to try it out.

Here you can find a tidier p2p program inspired by tinyp2p. It seems to use the Set datatype, so is probably specific to python 2.4, and is not compatible with tinyp2p, but it is much easier to read.

Ed Felton of freedom-to-tinker has released a tiny 15 line Python program called TinyP2P which allows you to create a simple (if not secure or scaleable) file sharing network. Get the code here. It’s cute, and might not be bad for tiny bits of file sharing.

Addendum: Actually trying to run it, I got

localhost - - [15/Dec/2004 15:53:33] "POST /RPC2 HTTP/1.0" 200 -
Traceback (most recent call last):
  File "../tinyp2p.py", line 14, in ?
    for url in pxy(ar[3]).f(pw(ar[3]),0,[]):
  File "/u0/markv/my-python/lib/python2.3/xmlrpclib.py", line 1029, in __call__
    return self.__send(self.__name, args)
  File "/u0/markv/my-python/lib/python2.3/xmlrpclib.py", line 1316, in __request    verbose=self.__verbose
  File "/u0/markv/my-python/lib/python2.3/xmlrpclib.py", line 1080, in request
    return self._parse_response(h.getfile(), sock)
  File "/u0/markv/my-python/lib/python2.3/xmlrpclib.py", line 1219, in _parse_response
    return u.close()
  File "/u0/markv/my-python/lib/python2.3/xmlrpclib.py", line 742, in close
    raise Fault(**self._stack[0])
xmlrpclib.Fault: 

The Python Cookbook has a new entry which I thought was especially clever, and perhaps the only really good use of eval that I’ve ever seen. It is a class which simulates a spreadsheet. It is clever because it uses a class which simulates a dictionary as an environment in which to evaluate expressions. Quite clever, and very short.

Two things are occupying my mind this morning: the first: an internal reminder to pay my mortgage today, and the second is that Python 2.4 has been officially released.

Notable changes in Python 2.4 include improvements to the importing of modules, function decorators, generator expressions, a number of new modules (including subprocess, decimal and cookielib) and a host of bug fixes and other improvements.

The Python Daily URL! feed has had quite a few articles lately on the so-called “decorator” syntax. I must admit, I’m not really up on the controversy, but I was amazed that even after reading three or four posts, I still couldn’t figure out what the intended utility of the new feature was supposed to be. I suppose it’s because I’m hopelessly out lunch with respect to certain OOP practices, but still: I’m not a programming language newbie.

Whether I’m right or not, it does not bode well for the trend that Python is taking. I’m not the only one who is noticing. Python is sprouting new features which increase the spartan simplicity and expressive nature of the underlying language, complicate it’s implementation and give very marginal utility in return.

Personal (if second hand) anecdote: While attending the University of Oregon in the late 1980’s, I had the pleasure of having Will Clinger as one of my professors. Will was the author of the Revised Report on Scheme: the master work which describes what Scheme was, what it required and gave the semantics for the language. It was a remarkably terse document. In contrast, the specification for Common Lisp was being worked on by Guy Steele. The Common Lisp specification was large, cumbersome and while Common Lisp was more feature-rich, it seemed like a lot of work to implement all facets of the language, and there were many things included in the specification which were of marginal utility. Sound familiar?

Clinger described the situation to me thusly: when presented with a potential new feature for the Scheme specification, he asked himself two questions:

• Can this feature be implemented using machinery allready in the Scheme specification? If yes, then it is better to implement it that way, and not pollute the base language. This criterion eliminated unnecessary language changes that were largely semantic.
• If this feature couldn’t be implemented using the existing language, then is this feature the best idea which implements the desired effect? At the time, they were working on the Scheme macro facility, and they were working very hard to make sure that they implemented the best macro facility they could.

By contrast, Clinger characterized Steele’s approach as roughly “If each additional feature is of some use to somebody, and only marginally complicates the language, then who am I to oppose?” This is no doubt at least partly due to the business forces which already were heavily invested in various versions of Lisp, and therefore had a vested interest in seeing their own pet extensions merged with the language specification. Still, this “default is to accept” notion is very damaging to the tidiness of language specifications.

I fear that in the future, some of Python’s expressiveness will be clouded by dozens of features which are of marginal utility. We shall see.

Aether is a simple weblog/website authoring system written by Paul Harrison. He’s also got some other cool stuff that he’s written, including GIMP plugins for texture synthesis. He’s also got an electronic singing tortoise.

Mark Pilgrim has released a new version of his Universal Feed Parser. I have mixed feelings about the long term viability of this code, since it parses feeds which do not meet the specifications, which ultimately means that people never fix their broken feeds, but the specification itself is wooly enough that this is perhaps unavoidable. In any case, I’ve used it before, it works, and he seems to have done a lot of work generating test cases for it. Give it a try.

I’m a bit of a classic cryptography nut, and I also have had a lot of fun writing bits of Python code. Python is awfully good at sucking up text files and performing statistics and the like, so I thought I would go ahead and describe some of the fun things I’ve been doing.

I’ve developed code to crack fairly sophisticated ciphers before, including both the Playfair and Enigma machines, but I thought it might be fun to work on a simple python script to crack ordinary substitution ciphers using evolutionary computation. You would probably get better results from using a dictionary based attack, but I thought this would be both simple and fun. (more…)

Python 2.3.4 is out. Just a bugfix release. FreeBSD 4.10 was also released earlier this week. This is the first “Errata Branch”, which will include security fixes and other significant and well tested fixes.