More on PEP8

Well I certainly got some robust comments on my previous PEP8 post. A few people chimed on my side, so to speak. Someone else found it “discouraging” when faced with “non-compliant code”. But it was Luke who obviously felt most strongly about the matter, and it’s his points that I’m really addressing here.

First of all, it seems that you’ve got me coming and going: on the one hand, I’m unreasonable to expect people to adopt my project’s style when contributing to it; but on the other I’m unreasonable if I expect to program the same way in every environment. Let me say again what I said in the previous post: if I contribute to, say, core Python, then I *do* expect to have to change my style to match the project guidelines. Likewise, if I contribute to Pyro — a fairly well-known Python project — then I use camelCase method names, because that’s what its maintainer uses. I don’t find that so very difficult and I doubt it anyone else does either. (Of course my “anyone else does” here is as anecdotal as the generalisations in Luke’s comments and can be treated the same way).

Luke’s basic point seems to be that all Python code *should* look the same, regardless of any other consideration, and that to do otherwise is not to be a team player, to indicate that you don’t care, and to leave open the suspicion that your code is of as poor quality as… well, your PEP8-ness. And I find that position far beyond what I consider reasonable. If that leaves me turning people away at the door then please write and tell me. Perhaps I’m being a single-minded curmudgeon on this issue, but I am honestly bemused at the idea that *all* Python code should follow what is, basically, one person’s preferences.

In short, I would be genuinely interested to hear from other people if they think that publishing Python code which follows a consistent style but which is not PEP8-compliant is that much of an issue. For them, for would-be contributors, or for the image of Python.

21 Comments so far »

  1. OpenID said,

    Wrote on March 29, 2012 @ 9:19 pm

    Personally I find PEP8 a bonus in Python and a goal I try to work towards. There are automated tools to help make sure I use that standard and I love that, when it comes to Python, it’s easy to point at PEP8 and just start working forward vs debating styles. The tools make sure it’s kept to and consistent, and when I learn the tricks/workings I don’t have to worry about changing around.

    In practice, not everyone does follow it. My day job has their own tweaks, but I do keep hoping there’s a day when we just all get behind the standard and while we might not personally prefer each item in it, the benefit of following as a whole outweighs my small tweaks I would make if I was writing my own standard.

  2. Casey Duncan said,

    Wrote on March 29, 2012 @ 9:25 pm

    pep-8 zealotry is really just a manifestation of Sayre’s Law (’s_law). Practically everyone feel qualified to have an opinion on it, and many strongly do, even if what’s at stake is wholly subjective and often trivial.

    It is treated as dogma, and as such it creates zealotry. The same people inflamed by another style will also quote the dogma that “consistency is the hobgoblin of small minds”. You cannot win 8^)

    Luckily pep-8 itself is more pragmatic, as you know. Even some notable old timers in core dev have their own styles (i.e., Barry Warsaw). And of course Python itself is far from pep-8 compliant since much of its code predates it.

    My philosophy is to follow it in as much as there is no stronger local opinion, whether that be historical, personal, or by the project leader. If someone judges your code based solely on its pep-8 compliance, they deserve to be unhappy with it. I really dislike folks that break apis in the name of pep-8, that’s just silly.

    There are plenty of other things to be dogmatic about, how about licenses?

  3. Greg said,

    Wrote on March 29, 2012 @ 9:55 pm

    Non-PEP8 compliant code is a huge turnoff for me, personally. PEP8 gives you a model for consistency, for you and all of your contributors to use without you having to write and teach your own style. I have very little interest in reading your style guide in most cases, I just want to fork, fix, and pull request, then get back to shipping my stuff.

    Very few projects that drastically diverge from PEP8 have nice, consistently formatted/written code. In the case of a strong divergence, unless you have an excellently detailed style guide, people will just approximate what they see throughout the codebase, and often do a bad job at it. PEP8 spells it all out.

    PEP8 was polished over a long period of time, is generally familiar to most developers who care enough about quality to read it, and it leads to very readable, “pretty” code, IMHO. Everyone being on the same page trumps personal preference for my projects.

  4. Matt B said,

    Wrote on March 29, 2012 @ 10:33 pm

    Python has fewer style decisions to make than nearly any other language, and PEP8 is a restrained set of guidelines in my opinion. So I do raise an eyebrow when I encounter code that ignores PEP8, more so than I would for other languages. In C or Java, spacing and brackets are a matter of taste. In Python, we don’t waste time on such procrasturbation–we follow PEP8 and write the code, generally speaking.

    At my current employer, we’re polishing several large projects to release as open source, and combing them for PEP8 compliance was a given, even for those two coworkers of mine who don’t hew to it in general. Backfilling docstrings and conforming to common python style are something we also considered necessary before allowing potential funders to read the code.

    All other things being equal, we would choose a PEP8-formatted project over a non-compliant one. Just as we’d choose the one with a LICENSE and README over the one without, or the one with commit activity over the long-dormant one. It’s another indicator of health and investment in the larger python community.

  5. OpenID said,

    Wrote on March 29, 2012 @ 10:40 pm

    Certainly this whole discussions don’t have really any value. It really doesn’t matter how are pieces of code intended, so whole value of PEP-8 is that provides a neutral rule which can be used as a platform for consensus.

    When I see somebody who intentionally making life more difficult to others by insisting on something else than PEP-8, it is a warning sign for me, that this maintainer puts his opinions (even about thing which really don’t matter) above generally accepted consensus. Not mentioning that such maintainer makes life difficult for people with tools which work best with PEP-8 formatted code (e.g., PyDev).

    I think you have it in a wrong direction. Question is not whether you have right to have your code formatted as you wish. You certainly have. However, I believe that the real question is whether she is making contribution to his project as simple as possible.

    Just saying.


  6. OpenID said,

    Wrote on March 29, 2012 @ 10:42 pm

    sorry for typos and grammar mistakes, it is late and my English got progressively worse.

  7. Adam Skutt said,

    Wrote on March 29, 2012 @ 11:06 pm

    There might be merit if PEP 8 was a reasonable standard. It’s plainly not a reasonable standard, so there’s no particular reason to comply with all of it. Rationale on lots of things isn’t justified and some of the stuff is just downright archaic.

    Plus, as others have noted, even the Python language itself isn’t fully compliant, so expecting other’s code to be compliant is obviously silly. If it were that important then everything would have been fixed at 2 -> 3.

  8. Krys said,

    Wrote on March 30, 2012 @ 12:00 am

    I greatly value pep-8 as I believe a consistant style across disperate projects improves readability greatly. That said, I see no harm in small variations like 2 spaces instead of 4, for example. In fact my “house style” includes a couple small variations. And internal consistency is the most important aspect of any code style.

    However, I also find projects whose style is greatly different much harder to reason about and use. It is hard to keep a foreign code style straight until you get used to it and it is jarring when combining dependencies with different styles. In fact, I gave up on using Kamaelia because their code style, while consistant, is completely different and I found it very unappealing. Too bad too, because I love the projects design metaphor.

    Anyway, that is my $0.02. As long as you are mostly pep-8, then that is probably fine. Though the history and fall of Unix might suggest otherwise. :)

    Hope this helps. Good luck!

  9. Craig said,

    Wrote on March 30, 2012 @ 1:58 am

    I’m at first a C programmer so I’m used to ugly code :) That being said, PEP-8 is a good idea and to me is a sensible set of defaults.

    I think your method of using your style for your project and adopting the given style for other projects is a nice compromise as long as it doesn’t do you head in to switch styles.

    Reworking code just to match PEP8 seems a bit excessive but its presence removes all that ‘what style should we be using here’ discussion for anything new. Also code that follows that standard can be picked up by anyone that follows it, rather than adopting a different style.

  10. Pixy Misa said,

    Wrote on March 30, 2012 @ 3:02 am

    PEP 8 is a good set of guidelines, except when it isn’t. The line length rule is just silly these days. And some of the things it deems acceptable I find intolerably ugly.

    And even when it’s a good set of guidelines, it’s only a set of guidelines. It should never be taken to override all other considerations. That’s just zealotry, as Casey Duncan pointed out, and has nothing to do with good code.

    That said, putting a space between the function name and the open parenthesis? Dude, that’s just nasty. ;)

  11. Thomas said,

    Wrote on March 30, 2012 @ 6:33 am

    Just like PEP8 says, new projects new stuff should follow pep8 guidelines, otherwise python enviroment will be messy world. As for existing projects with different styling, it would not be wise mix stylings, so just leave them be.

  12. Gael Varoquaux said,

    Wrote on March 30, 2012 @ 7:19 am

    I agree with Luke: having all Python code look the same is a huge benefit. I really appreciate to be ablr to pick up any code and have it feel like I wrote it. It makes me more likely to use it, and potentially to contribute patches.

  13. Nick said,

    Wrote on March 30, 2012 @ 9:33 am

    The PEP itself even says that a good reason to not follow it is if a project already uses another scheme. That said, PEP8 is conveniently already written out and justified, and most people know about it, which makes it much easier to establish a convention in a group project.

  14. Ben Sizer said,

    Wrote on March 30, 2012 @ 11:28 am

    PEP8 says, “Consistency with this style guide is important. Consistency within a project is more important.” And that should be the last word on it. I think that anybody with an extreme view on your code due to PEP8 ‘compliance’ is being rather extreme. I’ve worked with a variety of languages and a variety of syntactic standards within each language and it really doesn’t matter. It takes 2 minutes to work out what sort of standard is in place and maybe 5 minutes to adapt to it.

    Personally, I aim for PEP8-like. I follow the arbitrary naming conventions (because you need a convention and PEP8 seems as good as any) but I don’t limit line length, I don’t make my docstrings so spacious, etc. But anyone who can’t work with my code because it doesn’t precisely fit some document… the problem lies with their adaptability.

  15. Enrol said,

    Wrote on March 30, 2012 @ 2:05 pm

    I think PEP8 is as good as many other style guidelines. Personally I find it comfortable with my coding habits but this is style, nothing more.
    But having a community that tries to use the same style is a plus. When you read code from several projects or contribute to different ones, a common style is very appreciated. And the effort to use it is minimal.

  16. Tom Davis said,

    Wrote on March 30, 2012 @ 2:23 pm

    For me, PEP8 informs a couple things:

    - Attention to detail
    - Familiarity with the Python ecosystem

    Basically, it tells me the author has the discipline to follow a style guide (either naturally or enforced via external tools) and that they’ve been using Python long enough to know about it in the first place.

    Now, does the lack of PEP8 inform the inverse? In reality, of course not. Twisted uses CamelCase because it predates PEP8 and Glyph eats puppies, for instance. Maybe your attention to detail is spent on your own personal style guide. I don’t know, nor am I arrogant enough to think I do. However, there are only so many hours in the day and countless third-party software projects; I’ve got to employ stereotypes as a time-saving measure to some extent.

    All things being equal, if software violates PEP8 in really flagrant ways (like using two spaces instead of four), that represents a cognitive load to me (however small) and my stereotypes indicate the author may be less experienced in Python than I’d like for a third-party package. This has held true more often than not, so I stick with it. If the author’s software provides something I can’t find anywhere else, I’ll reluctantly give it a more thorough read. If not, I’ll just choose another package.

  17. Travis Bradshaw said,

    Wrote on March 30, 2012 @ 3:08 pm

    In your last post, I was mostly on board… until “function ()”.

    I think there are excellent lexical reasons to “function()” as a representation of the calling mechanism that Python uses, and I think it profoundly affects code readability.

    When I saw that you “function ()”, I thought, “Yup, I bet this guy gets a lot of backlash for not being PEP8 compliant, he’s picked a particularly ugly personal style for Python.”

    My personal Python style definitely diverges from PEP8, I use 119 columns instead of 79, I wrap expressions before the symbol rather than after the symbol–like in standard math style, the next line starts with + instead of the previous line ending with +. But I’ve never gotten more than a shrug or a polite question about it.

    I think what you might be getting is the “PEP8 as the first and last factual argument for code style in Python” effect in the Python community when it comes to talking about the merits of code style. Maybe instead of thinking about those complaints as “I’m a stickler for doctrine”, maybe those complaints are actually “I don’t like your personal code style.”

    (Of course, of course, of course, you can code your own projects in any way you’d like. But maybe it’s not a matter of personal freedom, maybe it’s just that you’ve picked an unpopular style. :) )

  18. Chris Graham said,

    Wrote on March 30, 2012 @ 5:45 pm

    I think the main positive of thinking of PEP8 as the overall community wide standard rather than a standard specific to the source of Python itself is that while it doesn’t prevent style wars it at least serves as a default way of doing things that you use unless you have a good reason not to. Absent of that you have things common in other languages like multiple curly brace positioning styles that are all equally popular and constantly lead to fights over which is better even though they are completely arbitrary style decisions.

    Now that said, there’s no reason to say that absolutely all code has to follow the default style standard. Obviously coders have their own idiosyncratic style preferences and there’s always going to be some difference in how one person writes code versus how another person would. Personally I’m a fan of pretty printing systems that enforce a particular style and can be used to export code in any arbitrary style, although that generally works better in a setting where one IDE is dominantly used across the whole community. Overall I think as someone with a quirky coding style it just makes sense to acknowledge that your style might be “wrong” in terms of the standard, but that you like the “wrong” way better. For example I like viewing code on a big screen with a tiny font, so a width of more than the standard in most languages works better for me personally, but it’s understandable that doing that makes it harder for other coders to read and work with my code if I leave it like that.

  19. Harry said,

    Wrote on March 30, 2012 @ 8:40 pm

    I am glad to see PEP8, which is a suggestion on style that I try to adhere to at all times, and it shows that Python is from/for experienced programmers in the sense that all areas are covered.

    “then I use camelCase method names”
    Wouldn’t that be half-camelCase (camel case comes from formula notation and so all first letters are caps, NaCl, etc.)?

  20. James Thiele said,

    Wrote on March 30, 2012 @ 9:32 pm

    As a long time C programmer I’ve seen heated arguments about where braces should be put. I don’t care as long as they are consistent within a given source code file. When I start a new C file I don’t know which style I’ll use - it depends on my mood.

    I once worked on a large Python project with over 200,000 lines of code built over a period of five years with up to 20 programers at any time which had no coding standards. When I had to work on a piece of code I never had a problem with reading the code.

    My only coding standard is to write readable code.

  21. Perrygeo said,

    Wrote on April 2, 2012 @ 7:15 am

    Pep8 makes sense for most code. I try to stick with it as language conventions can foster better communication.

    But some times it does not make sense - my biggest beef is the 80 char per line limit which seems to severely decrease readability if you use descriptive variable names… I have seen 120 char lines broken over 4 lines with unhelpful indentation which obfuscates the flow of the program. IOW breaking a 90 char line into two might make sense if there is a logical breakpoint; otherwise let the flow of the code determine line breaks within the limit of modern monitors.

Comment RSS · TrackBack URI

Leave a Comment


Sign in with your OpenID ?


Name: (Required)

E-mail: (Required)