The best and worst of django core - Alex Gaynor (djangocon.eu)¶

Tags: djangocon, django

Intention: just some fun walktrough of django’s internals and see if we can learn from them.

Code should be elegant, short, fast, have features and be tested and documented. But that’s a balancing act. Features take space, so they might not be so short. Fast might not lead to the most elegant code. A really good patch is changeset 14507, most aren’t that good. This one removes quite some code, has documentation, has tests, etc.

An advantage of new features: they expose bad parts in the code, which need refactoring. After refactoring, the basic code is more lovable which helps adding other features.

Code needs to keep up with the times. Alex discovered an old piece of code in django while making this presentation. An old piece that did not use a newer, more efficient built-in django function for removing items from the database. That was a quick fix, but it points at a limit to the amount of code you can maintain as a community.

A good part: email backends. Once that was refactored, adding a simple development print-to-stdout email backend took 25 lines of code. And a local memory testing email backend took 15 lines. Good! Finding common ground and solving the common problem in a generic way helps a lot.

Complexity: code tends to reflect the complexity of the problem it solves. If the problem is complex, the code might have to be complex, too. Just don’t make the code MORE complex than the problem it solves. A simple email sending API can stay simple as the problem is simple, for instance.