PEP8? Or not?

From time to time someone comments on some code example I’ve produced (or, indeed, one of my published modules) and makes the point that the code is not PEP8-compliant. The most common complaints are that I use spaces before function-call brackets — spam (”foo”) rather than spam(”foo”) — and that I use 2-space indents rather than 4.

Since I’ve written pretty much the same answer whenever this has been raised, I thought I might as well write it here and then point people towards it.

PEP 8 is the Python project’s code style guideline. I quote from the opening paragraph: “This document gives coding conventions for the Python code comprising the standard library in the main Python distribution.”. It is not a guideline for every piece of Python code ever written by anyone. On the odd occasion that I contribute code to the Python core I naturally ensure that my code complies with PEPs 7 & 8 for C & Python code respectively.

I’ve been using the format described above for well over 25 years of coding on different platforms & languages. Along with other aspects, it constitutes my personal “house style”. If anyone wished to contribute to any of my projects I would ask them to follow the same guidelines (or at least, not to complain when I reformatted their code to match my own).

FWIW I find the spam(”foo”) style cramped; no doubt some people find my spam (”foo”) style too loose. So be it. I’m genuinely astonished when people advocate 8-space indents (and I’d be a bit startled by 1-space indents). I find 4 spaces push the relevant code too far away too easily so I use 2 spaces. Barring manifest absurdities, such things are largely subjective.

So now you know: if you see code examples of mine, or are perusing my source code, be prepared for (gasp) non-PEP8 compliance!

8 Comments so far »

  1. Geo said,

    Wrote on March 27, 2012 @ 5:34 pm

    So I assume when you work in a team you stick to pep 8? Otherwise who decides what the coding conventions and what happens when you can agree?

  2. tim said,

    Wrote on March 27, 2012 @ 6:31 pm

    @Geo: when I work in a team, I stick to whatever coding conventions obtain in that project. If that means having to sit down and agree some, then surely we’d do that. The result might be PEP8 or it might not, depending on where everyone’s coming from.

  3. K Lars said,

    Wrote on March 27, 2012 @ 7:13 pm

    I begrudgingly adopted PEP8 style in my Mozilla work just to quiet the dogmatic gnashing of teeth and rending of garments.

    The hardest thing for me to adopt was the absurdly short line length. Since I’m no longer writing code on a VT52 terminal, I relished the freedom of typing beyond the 79th character.

    Parallel with the trend of having tube based amplifiers to drive speakers on MP3 players, I suppose that PEP8’s line length restriction is to accommodate the return of programming on punch cards.

  4. Luke Plant said,

    Wrote on March 27, 2012 @ 7:23 pm

    The problem with this approach is it basically says to anyone who *might* contribute to your projects that you are not interested.

    When there is already overwhelming standardisation on PEP8 for Python projects (at least for new projects), very few people will take the effort to configure their habits and editors to adjust to your style. Some editors often don’t make it easy to do anything but 4-spaces for indentations, since this is the default for Python and almost everyone sticks to it.

    “Readability counts” is deeply embedded philosophy in the Python community, and sticking to standard conventions is extremely helpful to readability:

    If I know that CAPITALS are generally constants, for example, I’m going to be stumped and caught out every time some code violates that. The same is true of matters of whitespace in code - whitespace gives strong hints that help me as I read, and every violation of the normal convention is a speed bump that will trip me up.

    So, when you ignore these conventions, most people, myself included, will tend to conclude that 1) you disagree with the Zen of Python and 2) you don’t care about other people who might read it. On that basis, I would 1) avoid using your code due to concerns about its general quality and 2) not bother to contribute back, because you don’t seem to be a team player (where ‘team’ includes the rest of the Python world).

    If that’s what you want, that’s fine, but I think you need to be aware of the signal you are sending. A good developer is always ready to sacrifice small personal habits for the benefit of people who will read their code, and this is one of the primary qualities I would look for in developers I want to work with.

    For example, I like functional style, and think use of map and filter are often more elegant that list comprehensions, even if you need to create a lambda on the fly to get the function you want. However, in the Python community I’ll normally use a list comprehension (unless there is a pre-existing function I can pass to map or filter that does exactly what I want).

    In the days of github and bitbucket, when for small projects you will want to be able to fork it in seconds and contribute patches in minutes, do you really think that people want to learn your specific coding style before contributing?

    Further, I’d say that the argument that you’ve used this style with lots of other platforms and languages counts against you - it says that you are going to program the same way no matter what the change in environment, rather than adapt. This might not be true of course - but it’s the impression you are giving.

  5. Katie Cunningham said,

    Wrote on March 27, 2012 @ 7:30 pm

    Yes!

    While I love beautiful code, someone waltzing in and dissing something I posted due to it not being PEP8 makes me want to pull out my hair. It’s often just distracting from the main issue, like complaining about there not being any cream-filled donuts in the Krispy Kreme box at the meeting.

  6. Nik Ridder said,

    Wrote on March 27, 2012 @ 11:55 pm

    I whole heatedly agree, especially with the 80 character limit. The only thing I would like to be enforced more strictly is indenting since it is relevant to the execution of the code.

  7. tim said,

    Wrote on March 28, 2012 @ 8:32 am

    Thanks to everyone for the comments so far. I’d like to emphasise that I’m not bashing PEP8 as such for work on the Python core. Like several of you, for example, I’m not personally mad about a 79-char limit, but it’s a reasonable choice. Likewise 4-space tabs, etc. My point is that: that’s what the Python core devs want; you don’t have to use the same.

    @Luke Plant: you make some good points. I’ll try to address them in a second post if I can find the time today.

  8. fox said,

    Wrote on March 28, 2012 @ 10:00 am

    I totally agree with Luke

    I think that PEP8 is a great guideline for good readability. Almost every piece of software I write is PEP8 compliant and reading non compliant software is quite discouraging for me if I’d like to send a patch or contribute in some way.
    I think that having a common style in every python code could increase readibility, remove the need of adapt to different styles and make contributing and patching easier.

Comment RSS · TrackBack URI

Leave a Comment

OpenID

Sign in with your OpenID ?

Anonymous

Name: (Required)

E-mail: (Required)

Website:

Comment: