Ian Bicking: the old part of his blog


While I agree with most of what you've said and would like to agree with the rest, I have to say that backwards compatibility has been a nightmare. This is not because the language hasn't been generally backwards compatible, but because of the internals and install.

When you upgrade Python on a Red Hat Linux box, everything may stop working. It turns out that the 'python' in the path is now /usr/lib/python2.2 (or whatever) which doesn't have the same site-packages. Fine, try to find the same packages and re-install them. Oops, half of them aren't recompiled for 2.2/2.3, etc. Recompile? You can copy the packages to the new site-packages directory, but then you get warnings (must go turn those off *in the code?!* or in another site.py!) and sometimes crashes.

The C interface is terrible. The old style/new style dichotimity is a nightmare. (Note to people starting a new language project: Make sure you plan for binary upgrades.)

We need a "final" binary format that will allow the C code to be upwards compatible, not forcing new versions to be backwards compatible. That's looking at the problem backwards.

Once that is accomplished, we need a *global* site package directory that all versions can use.

New versions should *replace* old versions, not co-exist. (Obviously co-existing should be supported, but the old version should be moved from the "default" install.)

I'm sure there's more -- this is off the top of my head.
Comment on The Future: Longhorn Shmonghorn