A reason to like broken Python

Python developers often want their code to be “Pythonic”, usually meaning that they want what they write to be particularly suited to the idiom of the language. To the beginner, this usually seems like an obviously good idea, but so vague as to be hard to put into practice. To be honest, I often opt for other, more painfully obvious criteria to evaluate my code, like: “Does it run without crashing?” This hasn’t always had the best outcomes for me.

Since these different criteria capture different aspects about what’s good about a piece of Python, it’s worth putting them into a table:

Table comparing Pythonic code with code that runs

As I filled in this table, I realized that I think that Pythonic code that doesn’t run is often better than non-Pythonic code that does. If it seems implausible that broken code could be better, hear me out. Except for the most disposable, throwaway scripts, it’s important to consider how much work it will take to fix or improve a piece code. Understanding Pythonic code will be mostly painless, so you’ll be well on your way to improving it. Understanding non-Pythonic code will be much more difficult, and even if it runs right now, it’s going to break as soon as you start messing with it.

So now I’m really motivated to have a more Pythonic coding practice. FWIW, I found this course by Michael Kennedy to be a helpful step in the right direction.

This entry was posted in language, python. Bookmark the permalink. Both comments and trackbacks are currently closed.
  • Subscribe to this blog

Skip to toolbar