And now for something completely Pythonic...

Probably everyone has heard of the automatic Computer Science paper generator written by three clever MIT students. Well, since I had a bit of time to spare (but was too tired for serious work) I adapted it for physics, especially solid state physics and neutron scattering.

The repository is public, and here is an example paper.

Oh yes, it's written in Perl. If I have a bit more time to spare, I'll perhaps translate it into Python. For now, I mostly adapted the content it generates, added a bit more math, stuff like that.

The amazing thing is how easy it was to adapt -- their "grammar" for papers is really easy to get into (and it doesn't have dollar signs!). Let us thank god no Java is involved, else it'd be one gigantic XML file, very handy to edit. Have a look at the rule file -- it should be clear within a few minutes how it works.

NB: if anyone doubted that English was the right choice for the academic language, that this works is a very compelling argument, isn't it?

As we all know, acceptance of Python 3 will depend to a great deal on library availability. Therefore the core team will support porting efforts as much as possible:

• For one, there is a new mailing list, python-porting@python.org (subscribe at the list’s home page; it will be available via gmane soon).
• Also, porting guides are being compiled in the Python wiki. Please feel free to add your own experiences, blog posts and resources!
  
• There are a few packages already available for Python3 on PyPI, they are listed here. I’m also generating a daily-updating graph of the number of Python 3 packages.

As for my own packages, I expect Pygments will be ported soon; most probably in the week after christmas. Sphinx will follow later, because I need to port the Docutils too (if no one beats me to it), but I will try to get this done ASAP.

The other thing that needs to be perfected for Python 3 to be adapted is the 2to3 tool, which I’m happy to say is a pleasure to hack on — and therefore I expect many developers to send patches and improvements while porting their own stuff, like e.g. Armin already does.

Happy porting!

After releasing Sphinx 0.5 and Pygments 1.0 yesterday, I had to relax somewhat, so I wrote something I've always missed: both for Python and my projects, many commits get an entry in the project's changelog file, so I end up writing the log message twice: once into the changelog, once as the commit message.

Since I've been playing around with Mercurial and its extensions, I did it as a new extension that wraps around the commit command: it looks if a new changelog entry is in the committed changes, and in that case lets the commit message default to this entry.

It has been really easy to implement this. Mercurial code is very clean and concise, and the API doesn't require you to call five methods on seven different instances just to get at a diff of changes.

The code is, of course, in a repo. It doesn't work with hg 1.0 because I'm too lazy to rewrite the nice command wrapping helper they added in the trunk :)

Since yesterday's release of Python 2.6 (which I'm sure you've heard all about it, so I won't repeat the usual list of whatsnew items), the docs have been unaccessible for a while, while we cleaned up a bit of a mess on our server.

They're now there, where you'd expect them, at docs.python.org. Also, I promise that this page will be updated often as we fix bugs or add new content, in contrast to the previous policy of one docs release per Python release (for which I don't want to blame anyone, it was understandable due to the complications of building the docs).

The docs are also ready for download now.

As some of you might have noticed, the new docs feature a new URL scheme (since the old URLs were generated by latex2html, and the pages were split differently). Currently, obsolete URLs (like http://docs.python.org/lib/module-os.html) redirect to the old 2.5 docs (which have a permanent home at http://www.python.org/doc/2.5.2), so that no broken links exist. However, we're working on a mapping to eventually redirect most old URLs to their counterparts in the new docs.

So, if you've visited a specific subpage of docs.python.org today and wondered why it hasn't "changed" yet, try to go there via the index.

So apparently people think of the Python documentation as a snore-fest. Compared to the Perl documentation, it apparently lacks wit and other entertaining qualities.

I don't want to dispute the main points, but note that this issue brings up an interesting point about the role of humor in different cultures. It is said that humor pervades every aspect of life in Anglo-Saxon cultures (an often cited example being president Reagan's "Honey, I forgot to duck" after being shot). Everyone is supposed and encouraged to show "humor and grace", even under pressure and in so-called "serious" situations. The British even go so far as to ridicule people taking themselves too seriously.

In contrast, Germans usually frown upon this kind of ever-present humorous subtext. There is humor, but it is assigned specific places and situations in life. People "joking" all the time are seen as "clowns" and dismissed quickly as incompetent fools. The lack of humor in everyday life is then invariably overcompensated in events like German carnival, which mostly consists of people trying so obsessively to be funny it's a sad thing to behold. I know, this is shameful. But at least you can't say we don't have any sense of humor.

Now, back to my two cents about the docs. I assume the Perl docs to be written mostly by Larry Wall and other Americans, while a good part of the Python docs were written by Guido himself, at least in the beginning. Others followed the style already present. Now, this is pure speculation on my part, but it may well be that the Dutch culture handles humor similar to the German one. I'm not implying Guido has a questionable sense of humor -- on the contrary, as his choice of name for Python shows -- but it probably just didn't occur to him to put jokes, allusions, word-plays, etc. into the text. And if that kind of style doesn't come naturally to you, it will seem artificial.

Just my two cents, of course.

Python now has semi-official Mercurial repositories too, thanks to so I thought I'd do a few quick timings on the trunk repo from hg and bzr.

The results are:

Action	hg 1.0.1 time	bzr 1.5 time	bzr 1.6 time	Remarks
clone/branch (*)	90 s	560 s	252 s	svn checkout: 33 s
on-disk size	178 MB	280 MB	280 MB	svn checkout: 153 MB
log 1 rev	0.2 s	5.8 s	4.4 s	r40073 (hg)/r40144 (bzr)
log last 10 revs	0.2 s	5.9 s	6.3 s
log all revs	7.8 s	16.2 s	18.4 s	from hot cache to file
diff 1 rev	0.3 s	1.0 s	1.1 s	r40073 (hg)/r40144 (bzr)
diff from rev to now	0.7 s	1.9 s	2.0 s	r40073 (hg)/r40144 (bzr)
cat file from rev	0.1 s	2.9 s	3.4 s	Objects/dictobject.c from r2000
cat file current rev	0.2 s	0.5 s	0.5 s	Objects/dictobject.c
annotate	0.7 s	4.4 s	5.6 s	Objects/dictobject.c with user and rev

(*) The machine I'm using has a very decent internet connection (about 5 MB/sec transfer from python.org), so this can be taken as a good estimate of processing time.

Disclaimers: I know these are not very comprehensive, but they are what Python core developers could expect when Python was to switch to one of those VCS. I'm using bzr 1.5 and hg 1.0.1. If I did anything wrong, it is because I'm not a bzr expert. UPDATE: Now also with bzr 1.6 timings.

The PSF board has decided to give the PSF community award to Brett Cannon and myself, for migrating the tracker to bugs.python.org and the docs to Sphinx, respectively. While this kind of recognition is not the reason for doing it, it's a great honor to be though worthy of the community's thanks. So, thank you very much, PSF!

It also shows that it can be advantageous, when choosing an Open Source project to contribute, to select a large project that has a foundation.

Now that I have to revise for my Physics exams, I finally have something else to put off, so I can write blog posts again. Yay!

There are some news about Sphinx:

• Christopher Perkins has posted a cool screencast at ShowMeDo showing off Sphinx and the doctest extension.
• Version 0.4.2 was released only a week ago, containing some bugfixes, and 0.4.3 is already in the making.
• The trunk has exciting new features too: Support for math (trivial for LaTeX output, and two alternatives for HTML -- JavaScript-based or PNG-image-based).
• Also there's Intersphinx, a new extension for linking between Sphinx docs for different projects.
  

More stuff is on the to-do list for 0.5: more versatile inclusion of code snippets, internationalization, file download support, and more. Stay tuned!

After a few weeks' bug-fixing releases, I've now released Sphinx 0.2. The list of changes is here – most are designed to make Sphinx more flexible to meet your documentation needs too.

Download it from Cheese ShopPyPI as usual.

If someone is interested, here are some slides of a (German) talk about Python 3000 I gave at the Munich User Group.