Wandering Thoughts archives

Apache's mod_wsgi and the Python 2 issue it creates

If you use Apache (as we do) and have relatively casual WSGI-based applications (again, as we do), then Apache's mod_wsgi is often the easiest way to deploy your WSGI application. Speaking as a system administrator, it's quite appealing to not have to manage a separate configuration and a separate daemon (and I still get process separation and different UIDs). But at the moment there is a little problem, at least for people (like us) who use their Unix distribution's provided version of Apache and mod_wsgi rather than build your own. The problem is that any given build of mod_wsgi only supports one version of (C)Python.

(Mod_wsgi contains an embedded CPython interpreter, although generally it's not literally embedded; instead mod_wsgi is linked to the appropriate libpython shared library.)

In the glorious future there will only be (some version of) Python 3, and this will not be an issue. All of your WSGI programs will be Python 3, mod_wsgi will use some version of Python 3, and everything will be relatively harmonious. In the current world, there is still a mixture of Python 2 and Python 3, and if you want to run a WSGI based program written in a different version of Python than your mod_wsgi supports, you will be sad. As a corollary of this, you just can't run both Python 2 and Python 3 WSGI applications under mod_wsgi in a single Apache.

Some distributions have both Python 2 and Python 3 versions of mod_wsgi available; this is the case for Ubuntu 20.04 (which answers something I wondered about last January). This at least lets you pick whether you're going to run Python 2 or Python 3 WSGI applications on any given system. Hopefully no current Unix restricts itself to only a Python 2 mod_wsgi, since there's an increasing number of WSGI frameworks that only run under Python 3.

(For example, Django last supported Python 2 in 1.11 LTS, which is no longer supported; support stopped some time last year.)

PS: Since I just looked it up, CentOS 7 has a Python 3 version of mod_wsgi in EPEL, and Ubuntu 18.04 has a Python 3 version in the standard repositories.

Improving my web reading with Martin Tournoij's "readable" Firefox bookmarklet

Not that long ago, I set up Martin Tournoij's "fixed" bookmarklet to deal with CSS fixed elements. When I did this, I also decided to install Tournoij's "readable" bookmarklet, because it was right there and it felt potentially useful. With it sitting in my tab bar, I started trying it out on sites that I found not so readable, or even vaguely marginally non-readable, and to my surprise it's been a major quality of life improvement on many sites. I've become quite glad that I made it conveniently available.

What the "readable" bookmarklet does is it goes through every <p>, <li>, and <div> to force the text colour, size, weight, line spacing, and font family to reasonable values. It doesn't try to set the background colour, but it turns out that a lot of sites use a basically white background, so forcing the text colour is sufficient. All of this sounds very basic, but the result can be really marvelous. It's especially impressive on sites that don't feel as if they have obviously terrible text, just text that's a bit annoying. It turns out that what feels 'a bit annoying' to me is often harder to read than I was consciously aware of.

Why such simple restyling works so well in practice is somewhat sad. It turns out that a lot of sites make terrible text styling choices for clear readability. The obvious case is too-small text, but beyond that a lot of sites turn out to set a lower-contrast text colour, such as some shade of grey, unusually thin text through either weight or font choice, or both at once. Undoubtedly they think that the result looks good and is perfectly readable, but increasingly my eyes disagree with them.

Because I looked it up, here is specifically what is being set by the current bookmarklet. Currently, the "readable" bookmarklet runs the following Javascript:

javascript:(function() {
    document.querySelectorAll('p, li, div').forEach(function(n) {
        n.style.color = '#000';
        n.style.font = '500 16px/1.7em sans-serif';
    });
})();

The n.style.color is simple; #000 is black. The n.style.font is a little bit more complex, because it's using the shorthand font property in a specific format. This format sets the font-weight to '500', which is just a little bit bolder than normal ('400' is normal), the font-size to 16 px (which these days is a device-independent thing), the line-height to 1.7 em for a pretty generous spacing between lines, and the font-family to your general sans-serif font. People who prefer serif fonts may want to change that to 'serif', and in general now that I look at it you might want to tinker with the 16px and the line spacing as well, depending on your preferences.

(My standard Firefox font is set to the default Fedora 'serif' font, currently DejaVu Serif according to Firefox, at size '15'. I could probably reasonably change the '16px/1.7em sans-serif' in the bookmarklet to '15px/1.5em serif' or so, but at the moment I don't feel inclined to do so; if I'm irritated enough to poke the bookmarklet, I might as well make the page really readable.)