Wandering Thoughts archives


The problem with compiling your own version of Python 3

I've previously mentioned in passing that I simply can't use Python 3 on some platforms because it's not there (or perhaps it's there only in an old and lacking version). As reported by Twirrim, in some places the popular answer to this issue is to say that I should just compile my own local version of Python 3 by hand (perhaps in a virtualenv). At this point most of the sysadmins in the audience are starting to get out of their chairs, but hold on for a moment; I want to make a general argument.

There is a spectrum of Python coding that ranges from big core systems that are very important down to casual utilities. For something that is already big and complex, the extra overhead of compiling a specific version of Python is small (you've probably already got complex installation and management procedures even if you've automated them) and can potentially increase the reliability of the result. Nor is the extra disk space for another copy of the Python interpreter likely to be a problem; even if the disk space used by your system doesn't dwarf it, your core system is important enough that the disk space doesn't matter. But all of this turns on its head for sufficiently little and casual utilities; because they're so small, building and maintaining a custom Python interpreter drastically increases the amount of effort required for them as a total system.

Somewhere on the line between big core systems and little casual utilities is an inflection point where the pragmatic costs of a custom Python interpreter exceed either or both of the benefits from the utilities and the benefits from using Python 3 instead of whatever version of Python 2 you already have. Once you hit it, 'install Python 3 to use this' ceases being a viable approach. Where exactly this inflection point is varies based on local conditions (including how you feel about various issues involved), but I argue that it always exists. So there are always going to be situations where you can't use your own version of Python 3 because the costs exceed the benefits.

(With that settled, the sysadmins can now come out of their chairs to argue about exactly where the inflection point is and point out any number of issues that push it much further up the scale of systems than one might expect.)

python/Python3CompileCost written at 23:48:11; Add Comment

Some thoughts on blog front pages in the modern era

Once upon a time, the front page of your blog was how people read and followed it. This drove a great many features of the standard blog front page, things like the tropism towards showing full entries and paged navigation that let you go back to the previous N entries and so on. However, that was a very long time ago and things are almost certainly much different today.

I'm sure that some people still read blogs they follow through the front page (I'll admit that I do that for some blogs for assorted reasons). But I don't think that this is the dominant use any more. My standard belief is that most people come to most blogs through web searches, which will put them on individual entries. For people who follow your blog, I think that most will do so either by syndication feeds or by links from the social web. In this sort of environment, what's the purpose of your blog's front page? I can see at least two: it's where you point people for an overview of your blogging when they follow a link from a social web profile (or a GitHub profile or the like), and it's one of the top places people will look if they read an entry then decide they like your writing in general and want to see more of it.

What this suggests to me is that traditional front pages may be effectively obsolete and in need of being rethought for the modern era. For instance, I can imagine a front page that progressively shortens entries as you go along, with the first entry or two shown in full, the next few entries shown with significant excerpts, and then increasingly minimal entries for at least a few more. Perhaps you should also have a 'greatest hits' section afterwards (or as an explicit sidebar on the front page). I also suspect that there's no real point in paged navigation on the front page any more; instead you might as well end the front page with a link to your full archives. Your front page would still be a starting point for people reading your blog but it would be a different sort of starting point, one more oriented towards a first time (and one time) visitor.

(This uses ideas and practices from Peter Donis and Aristotle Pagaltzis that they mentioned in comments on this entry.)

Of course all of this is rambling theorization so far, uniformed by trying to do any real research. I'm sure that people have written plenty of things about design patterns for modern blogs and people may even have measured how traffic flows to various places on various sorts of blogs; if I was serious need to find out what's the current state of the art. As usual, I lack the motivation and energy for that sort of large scale design overhaul, among other things.

(That sort of a major redesign is edging close to a 'blow up the world' exercise for me and if I did that a whole lot of things would change, more because it implies a major rethink about how the blog operates than because it would require a major code change.)

web/BlogFrontPageThoughts written at 02:18:40; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.