One of our projects in Mozambique will be to set up computer labs for several of the groups there. One of the questions is what operating system to use.

I haven’t personally run Windows since Windows 98 was their newest operating system (I did have an dual-booting Linux/XP laptop before you could buy linux laptops, but I rarely used it, this was 6 years ago). I had an Apple laptop for a while, but now all my computers are Linux. Still, I am trying to keep an open mind.

I do know that in these environments it’s not sufficient to just leave them a bunch of computers as they will quickly become unusable with viruses and spamware as kids install all sorts of things to get games to work (or to see pictures of unclad women). I know this from seeing it in other countries and from talking to our partners in Mozambique. Some intellectual tabloids have even pointed out how this is a problem for the wider internet.

The argument is thus for a Linux based solution where the typical user is allowed to run firefox (and only firefox) and more advanced users can run openoffice. By logging in remotely, a more advanced expert can do maintenance up to the point where the machines stop connecting to the internet.

I can’t probably give you an answer now as to what we will use, but if I found a good Linux distribution for this environment, it would make things much easier.

(And, no, Apple is not under consideration; the machines are too expensive).

Follow me on twitter: @luispedrocoelho

• django-gitcms: This has grown into a real reusable framework. The old adage of it’s reusable if you reuse it is true. Setting up pythonvision.org (still in Beta) led me to fix a lot of bugs.
• pymorph: This is almost ready to be called 1.0. It still needs more testing. So, if you find bugs, let me know.
• mahotas: More image processing in Python. This is implemented in C++, so the code is fast (compare the watershed implementation to that in pymorph: 10x faster).
• jug: Mostly performance improvements in the last round.
• milk: I had called this 0.1-alpha, 0.1-beta1, … Now, it’s just 0.1. It also includes a wrapper around the traditional libsvm code (instead of my port). After doing it, I realised that my port is much faster, though (because of the tighter integration with numpy).

It used to be that preparing a software release was a lot of work (build tar.gz file, upload it, test it, announce it,…). Now, in the Python world it’s a matter of python setup.py sdist upload). It makes it so much easier and anyone who is using pip can just get the newest version immediately.

Linux distributions still live the old release world where even small packages (such as the ones above) still need to go through a big process before making it into the main trunk. What would a Linux distribution with a release process that was as simple as python setup.py sdist upload look like? Add in unit tests and you should have a nice rolling release distribution.

Follow me on twitter: @luispedrocoelho

Follow me on twitter: @luispedrocoelho

I started using Django in June for a side project. A friend told me about it, he wanted to use it for a project we were going to do and it seemed great. Unfortunately, none of those projects went live (for non-technical reasons). A few months later, I am helping another friend with django-based website, and I also redid my personal website in django (albeit a very peculiar use of django) and I have other plans for django websites based on the framework I built for myself.

Two months ago, I decided to rewrite a website I manage (PAPS) in django. It was drupal-based, which had served us well, but it was, by now too old and inflexible. One of the things that disturbed me about it was that I had started tweaking the code. Not much, but enough that I was afraid to upgrade and lose those changes.

Also, I wanted recaptcha on signups, openid logins, twitter integration and a bit of a feeling of modernity. I worked on it a few hours per week, in the evenings, but I didn’t make much progress until I switched to Pylons. By then, I had invested a month into the project, but kept getting stuck and moving forward only at immense effort.

Django

First, the good: its documentation is deservedly regarded as impeccable and an example to us all. Its really easy to set up a very simple website and have it just work fast.

Now, the bad: One of the major reasons why I thought that django was so great was the vibrant community of people writing apps. However, I think that this also exposes django’s basic architectural flaw: the app system is not the right system to break up functionality. This is why there is so much talk of reusable apps: most existing ones are hard to reuse.

I first tried pinax or one of the content management systems. As usual, you get a working website instantly, but then you hit a productivity barrier very fast. Then, I tried a bunch of apps to get the pieces of functionality I wanted and get them to play together. What I wanted to avoid was to fork the code and
adapt it to my project. Then, I would be forced to maintain it and diverging from the main tree.

I tried. I really did. But I could never really get open id to work. I gave up on almost all of the apps I tried too. They would have a structure that didn’t fit into the rest of my application, I would need to tweak the templates (most by reading the code to see what was going on, which names it exported). I would need to fix the urls and url names. I would basically be forking each app to work with my desires instead of re-using it.

Fundamentally, the app model is the wrong abstraction for reuse in web-applications. I don’t have an answer, but I know that the app model does not work. How does, say, recaptcha authentication fit into the app model? What are its models, its views, its templates? It’s better handled as a different sort of reuse. What if I want to have a photo gallery and have the insertion of new photos trigger a tweet? I always end up taking someone’s code and modifying when what I wanted was to take someone’s code and call it.

What finally broke the camels back was when I was working with a django model and thought Sqlalchemy would be so much better. So, I decided to try Pylons.

Later that evening, I had ported almost all my existing work to Pylons. The next day, I had made progress. Also, I finally stopped feeling frustrated.

Pylons

Pylons seems to get a bit less attention. The reasoning seems to be: django is better for simple sites, Pylons for complex sites. Most sites are simple. Therefore, django is more popular.

What I finally figured is that, if you’re writing most of the code yourself or editing other people’s stuff so badly that you might as well start from a couple of snippets, what is django buying you?

I can use sqlalchemy and I can use mako as a templating engine. I never really liked django’s ORM nor its templating engine. I know you can change the template language, but then other apps get very unhappy. Use best of breed for your tools instead of not-invented here is a good principle.

The debugger that comes with Pylons is awesome: if there is an error in your code, you can actually get an HTML+Ajax python shell on the webpage where you can inspect the state of the programme. SQLAlchemy’s error messages are beautiful. Here’s a recent one (from FormAlchemy): No session found. Either bind a session explicitly, or specify relation options manually so FormAlchemy doesn’t try to autoload them.

Here’s a screenshot of the debugger.

Pylons Error

The contrast with django is immense. After months of daily use, I still feel stumped trying to decipher its error messages. Not always, but enough times that its frustrating. Just yesterday, another friend called me up on a Django problem. manage.py was not finding settings.py anymore because django plays around with the paths and the imports in a weird way and there was an impossible to understand relationships to recent changes because it worked in previous versions.

There is nothing wrong with magic in a system (rarely do you hear someone complain that their framework is too magical for working with files, just let me see the disk sectors). But unfinished magic is very frustrating. Unfinished magic most often manifests when the error messages are not magical. So, it just works or it just doesn’t work. As if your operating system spat out a bunch of references to virtual file systems and inodes when you mistyped a file name instead of saying File mixpelled.txt not found. Django has too much unfinished magic: if you make a little typo, then you get an obscure error in a place unrelated to your typo. SQLAlchemy is finished magic: half the time it even suggests a solution to
your problem.

Then there are the little irritations in django: the Sites app is obviously something that solved a problem in django’s original environment, but is a nuisance for the other 99% of cases. The fact that the username cannot be an email: Such a limitation is out of place in a general purpose framework.

I do miss the admin interface.

Summary

Django is good if your website is simple and Pylons is better if it is complex. I still agree with this statement, but I have lowered the bar for simple dramatically to mean “almost static” webpages. Pylons has a slightly higher learning curve and takes a bit of time to get to something that works well, but, if you know django, you can start writing code very very fast because most of the concepts are so similar.

The debugger on Pylons is so nice it makes it worth the switch.

Right now, unless my site was braindead simple, I would never go back to Django.

Follow me on twitter: @luispedrocoelho