Wandering Thoughts archives

A surprising lack in Python's standard library

Here's something that I am surprised is not already in the Python standard library: a simple module to generate and assemble HTML fragments (or if you prefer, general XML fragments), up to and including full HTML pages.

I find it especially surprising because not only is this something that a lot of people wind up needing to do sooner or later (consider generating error pages from inside a simple CGI program), but there's even a very common simple model for it that everyone seems to write their own version of:

from html import *
page = HTML(HEAD(TITLE("Qwerty")),
            BODY(H1("Qwerty's page"),
                 P("Some text goes here.")))
print page

(Details often vary considerably beyond the basic idea of nested objects with optional keyword arguments as the properties of the element.)

Now, you can argue that this is so simple to implement from scratch that it doesn't need to be in the standard library, but I have two replies. First, doing a good implementation is more work than it looks (consider quoting of bare strings and the Unicode issues, for example), and second, if lots of people are going to do it themselves, it makes sense to save everyone the effort and put a single quality implementation in the standard library.

Possibly the Python people consider this a terrible pattern to follow once you start getting beyond the very basics and think that there is a much superior interface. If so, it would be nice if an implementation of the better version was in the standard library; as it is, as far as I can tell there's absolutely nothing that will do this at all, although there are a number of things that will parse HTML and XML.

(It is possible that a simple HTML builder is hiding somewhere in the depths of the standard XML modules. In my defense, I will note that it's not obvious from skimming the library documentation and XML is not where I naturally look for 'simple'.)

Sidebar: pointers to some relevant resources

• HTML:EasyTags, one of the Perl versions of the same basic idea. Perl's implementation probably came first. (HTML::LoL is another interesting take on the overall idea.)

• XIST, which among many other features can do this. But it looks like a very big package, which brings up certain issues if I install it myself.

• markup.py is a single Python file and so easy to drop into a project, but it seems to not be intended to let you generate HTML fragments; instead you have to generate all of the HTML page in the proper sequence, which I find confining.

And hopefully I have missed something obvious in the standard library; if so, and if I find out about it, I'll add a note here.

What I want out of NFS security, at least at the moment

I know, NFS has a lot of new security features in both the more or less mythical NFS v4 and in NFS v3 with some hacks. The problem is that they all give me the wrong sort of security (as far as I can tell); like other real network filesystems, they're all focused on authenticating the users. What I want is good authentication of the hosts.

(The problem with user-based authentication is that it takes out all forms of setuid. This forces a really big, really drastic change in the fundamentals of how you structure your systems, which I am just not interested in exploring. I trust my systems, and I'd better, because they're all multi-user systems.)

The best way to authenticate hosts is for hosts to sign every NFS message, and then the other end to verify the signatures. At a minimum I'd like the host to be authenticated on each message; better would be message integrity validation as well. (Outright encryption is probably still too slow, and performance is important for me here; I can't suggest using something that cuts our NFS performance significantly.)

One can do this today with IPSec, but IPSec has two flaws for this: it's not integrated into NFS administration, and it's remarkably complex. One could probably solve both problems with a bunch of scripts, but then we'd have added another problem. And I'm don't know if current IPSec implementations can run fast enough to manage gigabit wire speeds, even just for host authentication.

(I'm also not sure if the authentication only modes are well regarded or well tested; I have the impression that most people feel that IPSec should be used with full encryption, which I believe is significantly slower than just authentication.)