The EuroPython juggernaut rumbles on... see you in Göteborg in 2005!
nconway: Well, at least a wikipedia-editing addiction is a useful addiction :-) So far I've only become addicted to reading it...
An interesting read, by the way. I've been thinking a bit about splines and interpolation and such recently, but in a rather different context. For a long time I've had an ill-informed interest in 3D graphics, and I've spent a small part of the last few weeks trying to turn this into a better informed interest. I've installed blender and played around with it a bit. I'm not sure how much I've learnt yet (apart from the fact that the blender interface almost defines idiosyncracy).
I've also spent a while trying to write a new version of Python's rather dogs-breakfast-y Extending and Embedding manual. It's still very much a work in progress, but if anyone has any comments, I'm all ears.
Hmm, advogato reappears just as I finally set up my own blog. Hmm, what to do. A potential advantage of my own blog is that I can hack on it to support various Emacs/reST-y integration issues, but that's only relavent if I get around to it...
Random Thought For The Day
At the ACCU conference a week or so back, Steve Alexander mentioned that the constituent parts of large Python projects he'd worked on were more loosely coupled than those of similarly sized Java projects.
I wonder if this is in part because of the prominence of unit testing in the Python world.
If you're trying to write a unit test for some object that requires you set up six billion other objects before you can create an instance of the class being tested (a) you don't have a unit test any more and (b) it's just really really annoying. It always helps when doing the wrong thing grates.
I doubt this counts as a particularly profound thought, but I've just now had it strike me. I guess this is also an XP-ish thing: when you come across something that smells bad like the tight coupling I've just been removing, do something about it. Like, now.
Another tangent to this is when you're doing test driven development (I don't feel I can capitalize that phrase in the context of what I've been doing for this particular personal hack) you really have to structure your program in a way that supports this methodology. I'm not sure people always realize this.
To pick two methodologies that in some sense are opposite extremes, consider the arguments that crop up from time to time between the static typing crowd and the unit testing crowd. The static typing crowd are used to structuring their programs in a way that maximizes the advantage of their methodology, i.e. crafting types in such a way that if your program compiles it has a damn good chance of doing what you want. The unit testers are experts at separating their problems into components that can be tested individually and writing thorough tests. I suspect that some of the reasons for the flamewars is a failure to appreciate the other "side's" practices.
(Hopefully you'll have noticed an assumption above that "static typing" means ML or Haskell or something like that. C coders just lose. Java I don't know much about but probably loses too. In C++ it's probably possible not to lose, but oh my, it hurts.)
As to which "side" is better, well, I'm not going to attempt an answer to that question :-) One thing to consider, though, is the side benefits of a given methodology such as the unit testing driving loose coupling. There are probably side benefits to the powerful static type system approach, too. I will notice that for sub-genius programmers, the unit test approach is probably just plain easier.
Of course, there no reason static typing and unit testing are mutually exclusive. Though, it seems to me that a unit test framework for ML (say) would have to include tests that 'merely' assert that some piece of code does or does not compile -- unit testing the type system, in other words. Hmm, the advantages of setting things down in prose: that last thought had definitely not occurred to me when I started this post... I wonder if any work has been done in this direction.
Oh yes, the hack I've been working on: a PowerPC assembler in pure Python :-)
This has its own special fun in that a failing test is more likely to show up as a core dump than as a traceback...
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!