Older blog entries for mwh (starting at number 195)

donscarletti: You're going to take an EXAM before you sleep again? Good luck mate, you're seriously going to need it :-)
14 Oct 2004 (updated 14 Oct 2004 at 13:26 UTC) »
7 Oct 2004 (updated 7 Oct 2004 at 16:02 UTC) »

The EuroPython juggernaut rumbles on... see you in Göteborg in 2005!

fxn: when you're trying to optimize a script with psyco, it's important to note that psyco can only speed code in functions, not module level code. But if most of the time is spent in expat, then, no, psyco ain't gonna make much difference.

nconway: Well, at least a wikipedia-editing addiction is a useful addiction :-) So far I've only become addicted to reading it...

raph: Surely the best way to improve the reputation of free fonts is to release some good ones?

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.

9 Jul 2004 (updated 9 Jul 2004 at 17:06 UTC) »

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...

ncm: Well, I'd probably mirror my own blog here in any case, and besides, that's what Planets are for.

We're just putting the finishing touches on the programme for EuroPython 2004.

My, what a lot of talks! Should be good — there's going to be some tough decisions on which track to follow at some points.

The world would be a scarier place if virus writers were less incompetent.

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.

The Hack

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...

Talk at EuroPython

You only have a week left to submit a talk at EuroPython 2004.

Or you can still register at the early bird rate for another fortnight or so.

It's going to be good!

186 older entries...

New Advogato Features

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!