Why PEP8?

In the Python world the PEP8 style guide is the canonical way to format code. It specifies such ridiculous things as spaces around operators, details about function names and even argument names, and import order. Why would such pedantia be respected? And what would anyone do with it?

Everybody has opinions about the way their code should be formatted. I find that mine vary from language to language and I try to fit in with the code around the new code I'm writing. In spite of trying to fit in the ambient space, my opinions about code formatting often sneak in. In a project with multiple coders (e.g. longterm colleagues), I find that it's often not too difficult to tell who wrote what code. I believe that software projects should be concerned about gross lacks of uniformity.

Why? One of my favorite pet reasons for concern is that non-uniform code leads to spurious changes in revision control. (And, yes, I care very much about whitespace changes in a commit log!) When a developer makes changes purely to code format while making other real changes they must make a choice -- either do a double commit with one for formatting and one for the actual functionality change or make one commit with both formatting and functionality changes. Either choice makes revision annotations more cumbersome than they need to be. A code standard which speaks to pedantia means everybody is using the same format and that means less purely format related changes.

There are other obvious reasons to care about uniformity -- proper name choices make libraries much more discoverable is one of the most crucial.

I've finally found a way to make PEP8 reality in my day-to-day code. I dabbled with pylint various times in the past, but it produced way too much chatter to be usable. If a check like this isn't fairly thoughtless it won't happen like it should and it should happen before every commit. My pylint strategy is to finetune the style rules in the rc file and quiet down some of the most obnoxious warnings. The next part of my strategy was a wrapper script which reads the output of pylint and further prunes errors in a more context sensitive way.

One example of context sensitive pruning is that Python's '*' imports are to be avoided. However, I actually use them a lot in one specific context -- __init__ files. With my wrapper script I can still warn about '*' imports where they shouldn't be and also put them in the in __init__ scripts with-out pylint pragmas.

Maybe someday I'll be able to post my codecheck.py wrapper script.

Author: Joel B. Mohler
Published on: Dec 11, 2014, 4:16:52 AM
Tags: code, python
Permalink - Source code

Inplace Swapping Variables

Long ago my high school computer science teacher posed the problem of swapping two variables with-out use of a temporary variable. I figured it out on the ride home from school. One of the primary sticking points was that many of the interim solutions I found imposed ridiculous constraints on the values. The solution I post here clearly works for "small enough" integers.

So long as your data type has a concept of a well behaved addition and no overflow from the values the following snippet of Python code illustrates the technique:

# reverse values in variables x & y
x = x + y
y = x - y # x+y - y = x
x = x - y # x+y - (x+y-y) = y

The 'x' and 'y' used in the post-fix comments are to be understood as the original values & the spacing is suggestive.

Author: Joel B. Mohler
Published on: Dec 5, 2014, 3:11:47 AM
Permalink - Source code