A bunch of my friends and colleagues have extolled the virtues of Python for web development. So in trying to keep with the trends, I’ve been tinkering around with Python – specifically Django. So far I’ve built one successful project that’s currently running on Heroku, and the other one is still in development since it’s a bit more involved. My conclusion thus far is that, while there are some nice parts to web dev in Django, overall I’m pretty underwhelmed.
So the clear caveat here is that all of this development is being done in Django. I picked Django because it’s the clear frontrunner in Python web development, and it makes decisions for you in terms of templating, ORM, and so on. Coming from PHP frameworks where those decisions are all baked into the framework you pick, it seemed to make the most sense. Awhile back I attempted to learn Flask, but the lack of documentation around about how to get SQLAlchemy and any of the templating engines to work with it really just made the whole thing a pain.
Anyway, on with the development. virtualenv is pretty nifty, I must say, and using it in conjunction with pip/easy_install makes life really easy. I did have a hard time getting pip to install MySQL-Python; for some reason, easy_install had, well, an easier time of it. (I’m running a Windows box, so that affected things.) In terms of code structure, Django’s way of doing development – by building functionality as separate applications and bringing them all together – is interesting. Working with forms is surprisingly easy, too. I built a form with dynamic inputs that populated related objects to an item, and with a little Javascript to get the form fields to show up, it just worked. Models are small and relatively unassuming, and routing makes sense. And of course, Django (and other Python frameworks) can handle a lot more requests than other languages.
But there are a lot of things that don’t really sit well with me. Having all your view functions handle multiple HTTP verbs seems less than ideal; it’d be cleaner, I think, to have one method for GET and another for POST. Since models extend from django.db, that means that they’re bound to the database versus being standalone objects that get fed to a database object that handles how they get stored. I wish the Django documentation actually recommended splitting up views.py into a more logical structure, as I can see how that file could get very long very quickly. I guess coming from the world of PHP’s PSR-1 where each class gets its own file, Django’s file structure just seems sort of disorganized.
As I’ve been working with Django to put together a project, I recently came to a conclusion: that it’s really just another way of getting things done. It’s not better or worse – it’s just different. At the end of the day, you’re taking input from the user, storing it in a database, and then displaying data back to the user. And working with Django really feels like that: yes, it does make some things easier to work with, but then there are other parts that are a bit more difficult or unwieldy. I think if the work I was doing involved interfacing with other components like hardware or offline interfaces like printers or something, then Python would make more sense – but for fairly standard web development, I guess I don’t really see a compelling reason to switch. Either way, it’s a good tool to have in my back pocket.
Leave a Reply