One aspect of Python programming that trips up those coming from languages like C or Java is how arguments are passed to functions in Python. At a more fundamental level, the confusion arises from a misunderstanding about Python object-centric data model and its treatment of assignment. When asked whether Python function calling model is "call-by-value" or "call-by-reference", the correct answer is: neither. Indeed, to try to shoe-horn those terms into a conversation about Python's model is misguided. "call-by-object," or "call-by-object-reference" is a more accurate way of describing it. But what does "call-by-object" even mean?

Read on →

Back in February, I wrote a post titled 'Starting a Django Project the Right Way', which still draws a consistent audience eight months later. In those eight months, Django has released version 1.4 of the framework, with 1.5 under active development and promising experimental support for Python 3.x. Given these changes, as well as the availability of new and updated resources available to Django developers, I decided to revisit the concept of best practices when starting a Django project.

The beginning of a project is a critical time. Choices are made that have long term consequences. There are a number of tutorials about how to get started with the Django framework, but few that discuss how to use Django in a professional way, using industry accepted best practices to make sure your project development scales as your application grows. A small bit of planning goes a long way towards making your life easier in the future.

By the end of this post, you will have

1. A fully functional Django 1.4 project
2. All resources under source control (with git or Mercurial)
3. Automated regression and unit testing (using the unittest library)
4. An environment independent install of your project (using virtualenv)
5. Automated deployment and testing (using Fabric)
6. Automatic database migrations (using South)
7. A development work flow that scales with your site.

None of these steps, except for perhaps the first, are covered in the official tutorial. They should be. If you're looking to start a new, production ready Django 1.4 project, look no further.

Read on →

After a surprisingly positive reception to my post Writing Idiomatic Python I decided to write an e-book (if you'd like updates on the book's progress, a sign up widget is available below). Having never done so before, I had no prior experience to guide me in how one should go about doing this. While I could have spent a week researching the topic, I decided writing was actually more important and I could figure the rest out as I go. Throughout this process, I've settled on an method for writing and testing the book, which is written entirely in Python (I'll explain below). I've noticed a number of interesting parallels to general project development in Python, hence this post.

Read on →

I've gotten such a positive response from the blog post that I've decided to turn it into a full-length e-book. See below for more information and to be notified when the e-book is ready.

Read on →

As someone who evangelizes Python at work, I read a lot of code written by professional programmers new to Python. I've written a good amount of Python code in my time, but I've certainly read far more. The single quickest way to increase maintainability and decrease 'simple' bugs is to strive to write idiomatic Python. Whereas some dynamic languages embrace the idea there being no 'right' way to solve a problem, the Python community generally appreciates the liberal use of 'Pythonic' solutions to problems. 'Pythonic' refers to the principles laid out in 'The Zen of Python' (try typing 'import this' in an interpreter...). One of those principles is

'There should be one-- and preferably only one --obvious way to do it'
                                                -from 'The Zen of Python' by Tim Peters

In that vein, I've begun compiling a list of Python idioms that programmers coming from other languages may find helpful. I know there are a ton of things not on here; it's merely a skeleton list that I'll add to over time. If you have a specific idiom you think should be added, let me know in the comments and I'll add it with attribution to the name you use in your comment.

Read on →