Pyblosxom 1.5.3 — the engine powering this blog — was last released in 2013 and officially targets Python 2.7. It does include a use_2to3 = True flag in its setup.py, which historically instructed setuptools to auto-convert the source at install time. That mechanism was removed from setuptools 58.0 (2021), so the package now installs as raw Python 2 code on modern systems.

The upgrade path to Python 3.12 required two layers of fixes:

Automated conversion via 2to3

The Dockerfile runs 2to3 -w -n over the installed Pyblosxom package directory at build time. This handles the bulk of the syntax differences (print statements, has_key(), except E, e style, etc.).

Manual patches for removed APIs

2to3 converts syntax but does not know about API removals. A startup script (patch_pyblosxom.py) applies targeted fixes each time the container starts, covering:

• __init__.py: implicit relative import from _version import → from ._version import
• crashhandling.py: cgi.escape removed in 3.8 → html.escape; StringIO.len attribute gone → len(output.getvalue())
• pyblosxom.py: entrylist.sort() on objects that only define __cmp__ (ignored in Python 3) → explicit key= lambda
• cache/base.py: 2to3 converted self.has_key(key) calls to key in self, which recurses infinitely because the class has no __contains__. Fixed by patching __getitem__ to call isCached() directly and adding a proper __contains__ method.
• plugins/markdown_parser.py: story.decode("utf-8").encode("utf-8") round-trip is meaningless on Python 3 strings → pass story directly.
• renderers/blosxom.py: "".join(content) fails when a stray bytes value slips through → decode any bytes items before joining.

The local plugins (bib.py, pycalendar.py, pyarchives.py, etc.) also needed porting: print statements, dict.has_key(), mixed tab/space indentation, and the _bibtex C extension (Python 2 only) was replaced with the pure-Python bibtexparser package.

What's the point of this you might be asking? Experimenting with AI and what it is capable of. Most of this tedious back and forth work was done by Claude. It's a pretty powerful paradigm if you can point it to the output and iterate semi-autonomously.

Mailsink got a makeover as well.

Planning to move this to Hugo eventually, but for now this has to do.

posted at 14:00 | path: /python | permanent link to this entry

The gevent wsgi server is very easy to use from Python. I wrote a convenient wrapper which starts pyblosxom under gevent. This can be used to either serve your blog locally for testing or to serve the live system. The nice thing is that it doesn't require an extra apache or nginx server just to start serving it.

Full source code is located here.

The important piece:

from gevent import monkey; monkey.patch_all()
from gevent.pool import Pool
from gevent.pywsgi import WSGIServer
from Pyblosxom import pyblosxom

def start(host='127.0.0.1', port=8007, threads=8):
    pool = Pool(threads)
    application = pyblosxom.PyBlosxomWSGIApp()
    server = WSGIServer((host, port), application, spawn=pool)
    server.serve_forever()

posted at 23:00 | path: /python | permanent link to this entry

The gevent wsgi server is one of the fastest out in the open. I switched part of my applications to it and everything worked fine after restarting the server and testing locally. Unfortunately my haproxy frontend loadbalancer is not able to see the new backend though. Turns out that gevent.wsgi does not support HTTP 1.0 which haproxy uses for health checking.

The simple solution is to use gevent.pywsgi. This has some performance penalty though.

An alternative might be (untested) to configure haproxy with HTTP 1.1 healthchecks:

option httpchk OPTIONS / 1.1

posted at 16:00 | path: /python | permanent link to this entry