PEP8 it is, then

Thanks to everyone who commented on my previous PEP8-related posts. It’s been quite an eye-opener for me to see how many people felt strongly that PEP8-compliance was a real must-have, not just for core Python itself but for any Python project. My own use of Python just about predates PEP8 itself, and certainly predates its more widespread adoption within the community. And, while I was aware that it was a default recommendation for someone seeking style guidelines, I don’t think I’d appreciated just how wide and strong its uptake was.

Of the comments made to my previous posts, only one outright dismissed PEP8; several spoke neutrally, more or less echoing the sentiments I’d expressed; but the majority which expressed a clear opinion made it strongly advisable, not to say mandatory, to follow PEP8 for one’s own (published) work.

So I’ve decided to switch to near-PEP8 style. (Note that pretty much everyone and every project varies a little, most commonly on the line length issue). The two key points which seemed — startlingly, from my perspective — to bother people the most were the two-space indents and the space-before-brackets. If you cared to peruse my winshell & active_directory github repos, you’ll note that those are now in line with PEP8. Others will follow as and when.

You’re probably not surprised to hear me say that, having made the switch, I can’t understand how anyone can prefer the PEP8 style. If I’ve switched, it’s not because I’ve had a sudden aesthetic revelation which makes me wonder why I wasn’t using 4-space indents all along. Quite the reverse: for the life of me I can’t see why anyone would prefer it. Rather, it’s because I recognise the value of a commonly-held standard within a community. And because, when I weighed it up, there was no reason — beyond my own preferences — not to switch.

I’ve tweaked my SciTE options and added the PEP8 module to my test scripts, turning off certain of the checks and allowing for slightly longer lines. Let’s see what I feel about this in a month or so’s time.

9 Comments so far »

  1. Grant Rettke said,

    Wrote on April 9, 2012 @ 4:21 pm

    Check this out:

    http://www.wisdomandwonder.com/link/6224/sayres-law

    I’m guilty of it too; I follow the standards for the language to try and avoid the whole discussion in the first place lol.

  2. Luke Plant said,

    Wrote on April 9, 2012 @ 5:26 pm

    FWIW, although I was one of the people who responded most strongly initially, I for one wouldn’t bother converting existing projects that have a consistent style, unless I really thought there were eager would-be contributors who were being put off. But for new projects I stick to PEP8.

  3. tim said,

    Wrote on April 9, 2012 @ 6:20 pm

    @Luke: to be honest, it was more of a move to show willing than because I saw a compelling need :)

  4. Robert said,

    Wrote on April 10, 2012 @ 12:33 am

    Wouldn’t it be great if someone could invent, like, a character, that meant “an indentation”, which could be inserted just once where needed yet would allow any reader to display that with as much horizontal spacing as they personally favour?

    If only…

  5. Simon Davy said,

    Wrote on April 10, 2012 @ 12:06 pm

    Kudos to you for preferring the community over your personal preferences.

    Respect.

  6. Greg said,

    Wrote on April 10, 2012 @ 4:41 pm

    The whole thing is silly. Honestly, I was attracted to Python way back when in part because PEP8 did not exist and camel case was widely enjoyed both by some core contributors and python coders in general. As a side note, over the years I have made some very minor Python library contributions.

    Use of PEP8 for non-core Python code is silly at best. There are no advantages to standardizing on any coding style outside of one’s personal and/or project standard or preference.

    Next the style-nazi will demand that all code is horrible unless it follows the Linux Kernel coding style…or Google’s coding style…or so on and so on. Such demands are unwarranted, unjustifiable, and completely baseless. Programmers adopt. At least good ones do. The entire world of comp-sci generally disproves these style-nazi every day.

    Honestly, I understand and appreciate the advantages of project coding styles and have absolutely no issue adhering to the standard of the day when called for. But if PEP8 is not in line with your personal coding style and standard, forcing yourself to use it for all projects is simply going to encourage bugs and typos until it becomes a new standard in your head. Obviously it will come, but why fight your own brain for the sake of fighting it. Not to mention there is something to be said for personal artistry.

    Ignoring all that, Python’s rejection of camel case is something of an annoyance as I honestly believe camel case is superior to that of underscore. Rejection of camel case in favor of underscore hinges of a massive amount of confusion and conflation which occurred at the same time Python became biased toward underscore and when anti-Microsoft politics and propaganda were at an all time high. Back then, far too many conflated (willingly and otherwise) camel case with Hungarian Notation (which employs camel case and is backed by Microsoft), in an effort to ignorantly bias and reject Microsoft and the Window’s platform. Which basically means, adoption of PEP8 and underscore is one of the largest examples of ignorance, biasness, and politics which exists in computer science. Its an eye sore of sorrowful politics over that of higher reason. After all, camel case was specifically adopted and offered wide appeal because it was widely believed to be superior to that of underscore. Back then, however, many were unable to make the distinction between camel case in general and Microsoft’s use of Hungarian Notation which sat atop camel case conventions.

    I personally dislike Hungarian Notation but IMO camel case is superior to that underscore, including the fact that it is contentiously more resistive to RSD than underscore because finger movements are by definition distributed throughout your personal heat map bias - as opposed to an extremely hot underscore.

    Sorry, but PEP8 for personal, non-Python core projects is for suckers and dishonest politicians with an agenda.

    References:
    http://en.wikipedia.org/wiki/CamelCase
    http://en.wikipedia.org/wiki/Hungarian_notation

  7. Brandon Rhodes said,

    Wrote on April 11, 2012 @ 5:30 pm

    Bravo for being willing to try it out — I have so often found that what looked ugly from a distance just wasn’t a problem once I was used to it. (I was quite struck the other day to see a snippet of Python presented in a Ruby keynote online, as an example of “how could people live with something so ugly” — this from someone whose language does not let functions be passed in a manner symmetric with all other values!)

    I like 4-space indents and all the rest, after 15 years or writing Python that way, because it “looks like Python” on the screen and helps me context-switch. Ruby’s 2 spaces make it “look Ruby” to me. When Python code uses some other number of spaces, then I get conflicting signals as I’m skimming over to another buffer in Emacs and trying to process quickly what I’m seeing.

  8. Piersy said,

    Wrote on April 13, 2012 @ 10:45 am

    This rather illustrates the old axiom about being damned if you do…

  9. Kay Hayen said,

    Wrote on April 13, 2012 @ 11:39 am

    I have not originally commented. But I refuse to use PEP8 for my project. I would rather have the code I read almost every day to be readable and to convey information in ways that are not allowed with PEP8.

    Instead I wrote down part my own coding rules, with different goals, if the code in question (Python compiler is my case) is not to be part of the library. And then I am going to complete that, and accept patches that violate my rules, and clean it up myself.

    If people are not willing to adapt at all, they probably will be unreasonable in other ways too. I am not convinced, that people who insist on PEP8 will actually contribute to the project.

    They are just angry about one obstacle there is. The removal of it, doesn’t make them contributors. I feel sorry for you, if I am right about that, because it would mean, you didn’t achieve your goal. On the other hand, let me know if that is not the case.

    That said, I will only deviate from PEP8 with good reason.

    Yours,
    Kay

Comment RSS · TrackBack URI

Leave a Comment

OpenID

Sign in with your OpenID ?

Anonymous

Name: (Required)

E-mail: (Required)

Website:

Comment: