E-Scribe : a programmer’s blog

About Me

PBX I'm Paul Bissex. I build web applications using open source software, especially Django. Started my career doing graphic design for newspapers and magazines in the '90s. Then wrote tech commentary and reviews for Wired, Salon, Chicago Tribune, and others you never heard of. Then I built operations software at a photography school. Then I helped big media serve 40 million pages a day. Then I worked on a translation services API doing millions of dollars of business. Now I'm building the core platform of a global startup accelerator. Feel free to email me.


I co-wrote "Python Web Development with Django". It was the first book to cover the long-awaited Django 1.0. Published by Addison-Wesley and still in print!


Built using Django, served with gunicorn and nginx. The database is SQLite. Hosted on a FreeBSD VPS at Johncompanies.com. Comment-spam protection by Akismet.


Pile o'Tags

Stuff I Use

Bitbucket, Debian Linux, Django, Emacs, FreeBSD, Git, jQuery, LaunchBar, macOS, Markdown, Mercurial, Python, S3, SQLite, Sublime Text, xmonad

Spam Report

At least 237138 pieces of comment spam killed since 2008, mostly via Akismet.

Making your way from PHP to Python and Django

"I'm a PHP programmer and I want to check out this Django thing. What should I do?"

I've been seeing this kind of question pop up more and more, and I have a few answers.

First-hand experience as well as many conversations with developers online have led me to the same conclusion: the curious person behind such a question should be encouraged and assisted. (I'll call that person "Pat" for the rest of the post, for convenience and conscientious gender-neutrality.)

Every developer who has come to Python and Django from some other web app technology could write a detailed memoir, in the guise of advice, on how it all went. Many have. Pat should read one or two.

Then, while still working away in PHP-land, Pat should:

Learn mod_rewrite

If using PHP, Pat is very likely using Apache. Apache has an extremely handy module called mod_rewrite that allows Pat to slice up requested URLs and feed them to scripts in just the right way.

E.g. with a one-line rule Pat can tell Apache to turn a requested URL like http://example.com/people/paul/ into a call to people.php?name=paul behind the scenes. Users get clean, readable URLs, and Pat get to structure code as desired. These rules use regular expressions, but that's not the main reason I recommend mod_rewrite in this situation.

I recommend it because a good set of those rules can translate remarkably cleanly into a set of URL-handling rules for a Django site, known as a URLconf.

Separate business logic from presentation

PHP is at its root a templating language. A key to happy PHP development in my experience was keeping the templating part separate from the business logic part. E.g. a main script assembles all the data that the page will need, then includes a template that takes that data and displays it.

Django, like most other web frameworks, enforces this separation to great effect.

Use indentation

Like other languages with C-like syntax, PHP doesn't care how you indent your code. However, Python (famously) does. For curly-brace programming, I like the Whitesmiths style, which happens to be nearly identical to standard Python style when you eliminate the lines containing the braces.

Consistently-formatted code in any language is easier to work with than the alternative. By cleaning things up Pat can make things better for Pat right now (as well as for those who work with Pat's code), and be happy with Python tomorrow!

Standardize on a back-end admin tool

No matter what kind of sites Pat builds, it's likely to involve making back-end administration tools. They may be used for updating text content, or adding database entries, or changing settings used across the site.

Everybody gets tired of building these things over and over, and doing it really well isn't easy.

My advice to Pat is, as much as possible, to standardize on a back-end tool that can be used for all projects. This may be something home-grown, or a general-purpose open source tool like PHPMyAdmin and friends, or a customizable open source application built for this use. That way Pat spends more time on interesting application code, and Pat's clients get a more consistent experience.

One of Django's gems is its bundled admin application, designed to work with any Django application you create. It's pretty, capable, and highly configurable. Best of all, you never have to write or maintain it, because it's already there for you.

Learn Python

This one may seem obvious. However, I've seen a lot of people dive into Django with no previous Python knowledge and end up wanting more. It's not impossible to learn both at the same time, but it's not necessary or even efficient. Luckily, there are a lot of books on Python out there in addition to good free resources.

Python is good for more than Django, of course. It's an excellent general-purpose programming language that Pat will be happy to use for all sorts of things. Writing utility scripts and other little things in Python is a great way to get comfortable before building that killer social networking app you've been dreaming of.

Saturday, November 22nd, 2008
+ + + + +

0 comments pending approval
Comment from Armin Ronacher , later that day

Urgh. Whitesmiths' style...

Comment from Bryan Helmig , later that day

Great post, this is exactly what I was looking for! I've been digging away at Python/Django for a bit now but can't seem to find many resources that detail building sample applications. If you know of any sites that do this, let me know. Also, if any sites that detail a programmers induction to Python/Django, let me know as well.

Comment from metapundit , later that day

I think the biggest hurdle for the average php freelance dev moving to django is deployment. With PHP you're usually working off the customers crappy PHP4 shared-hosting account - but PHP is preconfigured for you and just works.

Django has options so that even if you own the box things are a little more complicated (fastcgi, mod_wsgi or mod_python? Why do the docs say to use a separate server for static files? Etc etc.) And you aren't going to shoehorn it in very reliably even at the higher-end shared hosts like Dreamhost or Hostgator or what have you...

I think one of the first pieces of advice for PHP devs moving in a Python/Django direction is to upgrade your minimum hosting requirements. No more $4 hosting plans. Explain to the customer that it's cost effective! True you pay (say) $120 more per year for the hosting. But will cheap hosting (you know - no SSH, mod_rewrite not included, open a trouble ticket to change perms on a file or get a config directive added) cost the developer two hours in a year? Mos def - and there's the $100. Pick a host and buy new accounts for each customer or buy yourself a VPS, roll the price of hosting into your contracts and offer free hosting to your customers!

Once you've got decent hosting start with the next-to-last piece of advice. Build your PHP sites, but use Django as the admin backend. Deployment is less worrying (for a single user admin site you can use CGI to deploy Django - it's slow but it works). All you have to learn is two pieces of Django - models and admins - and both can start out strictly declarative (you don't even really need to know Python).

Pretty soon you'll be customising things a little bit, finding generic views, figuring out url routing and the templating language... Especially coming from editing old PHP4 code (say osCommerce) Python and Django are addictive...

Comment from metapundit , later that day

Oh - and Paul shouldn't you be pimping your book here? Wesley Chun brought a copy to Baypiggies the other night - It looks good...

Comment from Ron Craswell , later that day

Bryan, Eric Florenzano has done a really nice set of screen-casts that you can find at This Week in Django:


He goes through the process to build a site and you can get the entire source (and see the running version) at http://startthedark.com/

Comment from Michael Watkins , later that day

The best advice I can think of (other than spending some time learning Python at the interpreter) is to encourage the PHP programmer, now budding Pythonista, is to develop some CGI scripts in Python.

Forcing them to think about how bits of code emitting text actually make it from code through web server to the browser will be frustrating for a few that have never had to think about such things, but the knowledge they'll pick up from this simple exercise will be invaluable as they deal with why, sometimes, "things just don't work" (as another poster commented on earlier).

Spend the afternoon doing this before jumping into Django or Pylons or Turbogears or QP or Quixote or Twisted or Zope or web.py or ...

Comment from Yuppie , later that day

Hey, a very good post. But there are less django hoster around. Especially in germany.

It will take some time, till django can be used from everyone.

Comment from Paul , 1 day later

Armin - Sorry! My preference for Whitesmiths may betray my longtime aversion to curly-brace programming.

Bryan - there are lots of examples out there, including this set of links. For multiple detailed examples that include explanation as well as code, allow me to recommend our book.

metapundit - Look, I just pimped my book! Thanks for the kind words. Also, you're of course correct that deployment is a big issue. This came up the last time I wrote on this as well. I urge most newcomers to worry about deployment last, so as not to distract from the core Python and Django learning. The built-in development server is a great tool.

Michael - Interesting idea. Raw CGI programming will definitely increase appreciation of the value of the framework!

Yuppie - Yes, commercial support is still growing. Because of that as well as the reasons I gave above, this is something I urge Pat not to worry about at first. The situation may be quite different once launch-time approaches.

Comments are closed for this post. But I welcome questions/comments via email or Twitter.