PEP 8 Modernisation

http://hg.python.org/peps/rev/fb24c80e9afb

by tristaneuan • 13 years ago

213 141 13 years ago

hg.python.org

publicfig• 13 years ago

Nice to see some movement away from the 79 character limit. I've had to make some incredibly unreadable code in the past just to comply with it.

jsdalton• 13 years ago

Agreed. Text of the revised recommendation:

Aim to limit all lines to a maximum of 79 characters, but up to 99 characters is acceptable when it improves readability.

petsos• 13 years ago

Even the old PEP8 was stating:

    When applying the rule would make the code less readable, even for someone who is used to reading code that follows the rules.

nkuttler2• 13 years ago

Thing is the code will also become less readable for many people if your line is longer than 79 chars. My terminals have a fixed width so that they fit perfectly side by side on my multiple monitors. Using random higher numbers just means that I have to use random window sizes and what not.

Yeah, I could have 300 char wide terms, or 600 if I really wanted to. There was a reason for 79. There isn't for 99.

Edit: Glad to see that section might get an update http://bugs.python.org/issue18472#msg194086

Edit2: Gudio van Rossum proposes a patch https://codereview.appspot.com/12269044/diff/1/pep-0008.txt

rlpb9• 13 years ago

I'm in two minds. I prefer not to have to have everything too wide, as that messes up running editors side-by-side and for viewing side-by-side diffs.

I think I'm fine with it provided that readability doesn't suffer if my editor or viewer wraps line >79 characters. I don't want to be forced to make everything wider to see that extra readability. But if making it wider makes it more readable even if my editor wraps the line, then that makes sense.

B-Con• 13 years ago

Anyone changing their editor settings based on the new guidelines?

In vim, I'm thinking about using:

    set colorcolumn=79
    set textwidth=99

njharman• 13 years ago

"ignore = E501" is easy, free productivity and maintainability boost.

frou_dh3• 13 years ago

Nobody ever specifies whether or not 0x0a counts towards their limit.

http://i.imgur.com/LypKK8I.png

cjensen3• 13 years ago

The reason it's 79 instead of 80 is to allow for at least one funky glyph at the end of the line since many editors do that kind of thing.

jessaustin• 13 years ago

That's between lines, isn't it?

OTOH, 0x0d definitely counts toward the limit!

mattdeboard3• 13 years ago

I disagree, but only as of about 2 months ago. For awhile I stuck to 79 cols but understood if people elsewhere wanted to move to 100 or 120.

I've changed my mind because I've started doing a lot of code-reading on my phone. It's got a big screen (Galaxy S3) but even still, 80 columns is the perfect width to fit all the code on my screen without needing to scroll.

What's old is new again. We went from tiny monitors to huge monitors and now we're back to tiny "monitors" again. Anywhere where I am able to make the determination, 79 columns will be the standard.

jmduke• 13 years ago

Just curious: why are you reading code on your phone? I've heard of doing basic web-dev stuff via mobile (using stuff like Diet Coda) but rarely anything else.

tcdent2• 13 years ago

I've always used my best judgement. It's a peeve of mine that devs stick to that as a hard-and-fast rule, even when you're 1 or 2 characters over, and apply some crazy indent structure just to get past it.

While we're at it, can we ditch the convention of indenting arguments to line up with the method name? A single tab per-nested level will do.

antihero2• 13 years ago

I couldn't figure out if they have that dumb indentation rule.

https://gist.github.com/radiosilence/6133713

I mean how can anyone say that the former is better than the latter?

gsnedders• 13 years ago

Either is acceptable per PEP 8.

mattdeboard3• 13 years ago

What? There's no proscription against either of those. However a little common sense would go a long way in your first example. Break at spaces/hyphens/other natural break points in strings. Also the + symbols aren't necessary. String continuation is implicit inside parentheses.

bobisme2• 13 years ago

I always stick to 79 chars and stick to the latter method for indentation. I am completely happy with the readability of my code as a result. Thus, I'm not really happy with the new 99 char rule.

nohuck132• 13 years ago

Guido just proposed a patch that undoes this change and restores the old 79 character limit...

http://bugs.python.org/issue18472#msg194089

--- a/pep-0008.txt

+++ b/pep-0008.txt

@@ -159,12 +159,11 @@

Maximum Line Length

-------------------

-Aim to limit all lines to a maximum of 79 characters, but up to 99

-characters is acceptable when it improves readability.

+Limit all lines to a maximum of 79 characters.

EDIT: formatting/description

guelo• 13 years ago

The full patch also includes this:

  +Some teams strongly prefer a longer line length. For code maintained
  +exclusively or primarily by a team that can reach agreement on this
  +issue, it is okay to increase the line nominal line length from 80 to
  +100 characters (effectively increasing the maximum length to 99
  +characters), provided that comments and docstrings are still wrapped
  +at 72 characters.
  +
  +The Python standard library is conservative and requires limiting
  +lines to 79 characters (and docstrings/comments to 72).
  +

https://codereview.appspot.com/12269044/patch/1/1001

penguindev3• 13 years ago

My N=5 anecdote is the opposite; people who respect that limit have better looking - and simpler - code then those who don't.

There's a reason newspaper stories are in columns.

jowiar4• 13 years ago

    The default wrapping in most tools disrupts the visual structure of the code,
    making it more difficult to understand.

It's 2013. Let's fix the tools.

You think we would have gotten past the point of having to manually figure out "where should I break these lines for the best readability." Code is meant to be consumed by machines, and a machine should be capable of parsing the stuff, figuring out visual structure, and wrapping dynamically to account for window width and readable line-lengths in a way that preserves the visual structure.

alexchamberlain• 13 years ago

I'm sorry, but I disagree. As it stands, it is currently more important to display code as it appears in the file. One day, everyone may have their style for all languages and every tool supports it etc. That's not today.

jowiar4• 13 years ago

I agree. I'm saying this is a bug. The fact that we need to care about this is a bug.

If I'm working with code on my phone, I'm going to have different preferences than on my tablet, or my laptop, or doing side-by-side comparisons, or my 30" display, or a projector.

Probably the best current examples of what can be done with this are docco and it's friends. iPython notebook is another example of what we can do when we decide that hardware improvements in the past couple decades may be taken advantage of to improve production and consumption of code, rather than declaring that no progress shall be made after 1976.

frou_dh3• 13 years ago

Alrighty. Where will you be implementing it first?

NegativeK• 13 years ago

And how will you get every editor available on board?

_ZeD_• 13 years ago

Code is meant to be consumed by machines

I hope you're joking...

jowiar4• 13 years ago

Poor word choice on my part. The intention was that machines don't need to jump through any hoops to be able to figure out what code means - it's a language designed such that it can be parsed mechanically without ambiguity. Compare this to a machine interpreting English.

I was not intending to downplay the significance of code being intended for human consumption.

rlpb9• 13 years ago

Find me an alternative to side-by-side diff tools (such as meld) that work poorer with longer lines, and then we can talk.

Code is simply easier to read by humans when it isn't stretched out obtusely in one direction. We should be making code easier to be read by humans. Machines don't matter.

dilap2• 13 years ago

Completely agreed.

Newer versions of emacs do nice code wrapping (dynamically, to the width of the buffer, without modifying the buffer text). Xcode does nice code wrapping. I've stopped manually wrapping my code, and it's great.

rlpb9• 13 years ago

What do you do when you view a diff, and what you see there doesn't match your editor?

Edit: I know emacs can probably view diffs. That's not the point, unless you expect every window to be the same width, and every tool to wrap everything exactly the same.

memset• 13 years ago

I upvoted you for this - I think it's a really interesting idea.

Why can't my editor tokenize my code and then show it in the format I want? Why do I, as the programmer, have to worry about whether one whitespace convention works for you versus me, when you could just come up with whatever scheme you like and view code that way?

coldtea3• 13 years ago

Why can't my editor tokenize my code and then show it in the format I want?

Because editors are written by humans. And as of now, we haven't sold a whole lot of problems with their use.

For example, you get an IDE with lots of features, but a subpar editor, crammy UI and GC pauses (3 of the five most popular are written in Java).

Or you get something like VIM, with a great editor, but subpar compatibility with the rest of your system, not very good understanding of the code (refactoring, tokenizing etc). '80s GUI capabilities etc, ad-hoc collection of plugins to fix basic pain points (like file navigation).

Or you get Emacs, with millions of configurable options, a subpar extension language, script in various stages of great and rot, '80s GUI capabilities, etc.

In general, we lack tools that run the whole gamut: great editor, fluent shortcuts (either Emacs or Vim style), 2013 GUI capabilities, refactoring and intimate knowledge of program syntax (to the level of understanding the AST, no BS regex used for syntax highlighting), embedded REPLs and terminals, etc.

Something like a Lisp Machine + Smalltalk UI + Light Table + Visual Studio + Vim/Emacs combo.

sesqu2• 13 years ago

Well, there's stuff like word wrap and GNU indent and a host of pretty-printers, but I think you're looking for something more resource-intensive and integrated.

The question then becomes, why configure a transformer when you can just format it right the first time?

westurner• 13 years ago

Funny, someone was just talking about 79 characters per line in regards to using soft tabs for editor display consistency, the other day.

http://www.reddit.com/r/java/comments/1j7iv4/would_it_not_be...

These are useful for static code analysis and finding congruence with typesetting conventions:

https://pypi.python.org/pypi/flake8

https://pypi.python.org/pypi/condent

https://pypi.python.org/pypi/pep8ify

jneen2• 13 years ago

"Code is meant to be consumed by machines"

Well, partly. Code is actually a piece of writing intended for two very different audiences - one human, one machine. The machine doesn't actually care how long your lines are - this is an optimization for humans.

And I hear you about fixing the tools. Wouldn't it be easy if everyone used the same editor. But alas, this isn't a problem with the tools. It's an inherent limitation of text. That "figuring out visual structure" bit only works if your editor deeply understands your language. And different editors understand languages to different degrees and in different ways.

They say parsing is a solved problem, but I dare you to parse Ruby or Python correctly.

chrismorgan• 13 years ago

While Ruby and Perl cannot be parsed, Python can be parsed correctly.

eevee7• 13 years ago

No, thanks. Reasonably short lines means I can get a good idea of what's going on by skimming in one direction: downwards. If there are lines that run off towards the eastern horizon, even if they fit on my screen, I still have to follow along them to make sure nothing of interest is being hidden.

Plus, just getting the code to do the thing I want is enough work; let's not also start worrying about how to write code in such a way that most tools will understand how to wrap it. That sounds like bringing all the joys of CSS to my plain text. Because the tools are _not_ going to be perfect. Have you ever seen Perl code with punctuation in a comment at the end of a line, because some idiot syntax highlighter got confused about where a regex ended?

d23• 13 years ago

I'm disappointed to see this is still the top comment, for a few reasons.

1) Lines longer than 80 are an indicator that your code is getting too verbose, at least for Python. 2) You should be taking the time to figure out how to maximize readability of your code. And breaking the lines is damn near instantaneous when compared to the time taken to pick a good variable name or decide on overall design structure. 3) Not everyone will have the same editor. Your code should stand on its own and be readable in its own right.

baddox3• 13 years ago

1) Lines longer than 80 are an indicator that your code is getting too verbose, at least for Python.

I completely disagree, partly because I prefer to err on the side of verboseness, and partly because 80 is just ridiculously short. Look at the examples in PEP 8:

        def __init__(self, width, height,
                 color='black', emphasis=None, highlight=0):

What about that code is "too verbose"? It's an extremely simple constructor with 6 arguments (5 explicit).

I understand that readability is subjective, but I find it extremely hard to believe that anyone honestly finds that more readable on two lines than one.

crististm• 13 years ago

That is in stark contrast to SICP: "programs must be written for people to read, and only incidentally for machines to execute"

Whom should I listen to... Hmmm, tough choice...

I mean, I've just seen Gerry Sussman in a recent video saying he doesn't know how to compute, so you must be a winner.

kbenson2• 13 years ago

As pointed out to me by a friend that's forced to use the style guide at their new job, the Pet Peeves[1] section is somewhat ironic. It talks about avoiding extraneous whitespace (such as when lining up equal signs in variable declarations) and then proceeds to use extraneous whitespace in the Yes/No tags preceding code blocks. Apparently it does nothing for code readability, but it's useful for the information on the page...

  [1]: http://www.python.org/dev/peps/pep-0008/#pet-peeves

Buttons840• 13 years ago

The Yes/No tags are not code. The PEP is not advocating their style for all text documents.

kbenson2• 13 years ago

Obviously. Yet they are both presenting lists of items, with identifiers and values. I find expressing examples of a rule using a method the rule expressly outlines not to use (even if in a different language), ironic.

mhurron• 13 years ago

The tags aren't code though so the style guide wouldn't apply there. In this case they're lined up for clarity as to the differences between the lines.

/pedantic

raverbashing• 13 years ago

The only thing that makes me really sad is the aversion to tab indentation

I get it, it looks nicer with 4 spaces. I'm still not convinces it's a straight win.

(Of course, you should never mix tabs and spaces, and I'm glad Python 3 enforces this)

berdario4• 13 years ago

I'm one of the few guys who prefer tabs to spaces... but I actually find this change welcome:

before, some people criticized my choice believing that the PEP8 favored one of the 2 approaches, when in fact it just acknowledged that spaces were used more often, and in no case that was an excuse to change pre-existing code... there was some confusion

At least now I can/have-to concede that there's one preferred way

OTOH: I still find subpar the handling of space indentation in most editors nowaday (emacs, vim, gedit... you name it: they all behave similarly)... I could write some emacs-lisp to make the editor behave as I wish, but I never found that hitch worth scratching enough

redblacktree2• 13 years ago

What is the problem with space handling that makes it sub-par?

nemetroid• 13 years ago

You need to use spaces for alignment, so indenting with tabs and aligning stuff (in the way suggested by PEP8[0]) is impossible without mixing tabs and spaces.

[0] http://www.python.org/dev/peps/pep-0008/#maximum-line-length

berdario4• 13 years ago

If you read carefully, you'll see that you don't actually _need_ to align, you can always indent it further

In fact, I always found space-alignment cumbersome and sometimes ugly... always indenting with tabs was thus perfectly consistent

But that's the past, now :)

ekimekim• 13 years ago

YMMV but I always felt the spirit of that rule was "Don't mix tabs and spaces for indenting (ie. where it matters to the interpreter)".

Indeed, a quick test with python -tt shows that the tab-indent/space-align method does not throw an error, while using tabs and spaces to indent does.

cjensen3• 13 years ago

The problem is that many people and many editors conflate the 'tab key' and the ASCII TAB character.

Both Emacs and Vi correctly allow you to indent by 4 spaces rather than foolishly inserting a TAB and indenting by the standard 8. Other editors like Sublime Text stupidly insert a TAB and expect you to muck with how TABs are rendered in order to indent correctly.

Since many people don't understand that distinction, they map TAB to 4 columns which is incompatible with most formatters (including all printers and HTML). Switching to spaces is the only solution which really fixes this.

cocoflunchy• 13 years ago

Just add

    "translate_tabs_to_spaces": true

to your Preferences.sublime-settings to have spaces instead of tabs in Sublime Text.

kstrauser• 13 years ago

I'm using ST3 (and ST2 before that) with the default tab handling options, and it inserts spaces and not tabs. I don't think it'd have the rapid adoption among Python programmers if it didn't.

adamtj2• 13 years ago

I prefer not hitting tab at all because my editor already knows how far to indent. But when it does indent, I like it to use tab characters as a way to distinguish semantic indentation from alignment indentation.

And because emacs and vim are still "dumb" editors in some ways: They still conflate the arrow keys with "move one character", when they should really mean "move one character, unless you are in non-alignment indentation, in which case move one level of indentation, which happens to correspond to four spaces since this particular file is python." They have similar problems with backspace and delete, regexes and search/replace, etc.

Further, what if you prefer 2 or 3 space indentation? If you use semantic tabs, you can have that simply by changing the display width of the tab character. It needn't be equivalent in width to 8 characters. To my knowledge, emacs and vim are both too dumb to display code indented with spaces at a different indentation width than saved in the file.

Note that when using semantic tabs, tabs only represent semantic indentation. A new block adds a tab. Further indentation for the purpose of aligning multi-line statements must be done with spaces. Tabs following spaces on a line are always wrong. Tabs are not to be used to align to columns. If you want to do that, use spaces.

For example:

    def foo():
    --->if (long_named_function_that_returns_a_boolean() and
    --->....thing2() and thing3()):
    --->--->do_stuff()

And again, with your editor reconfigured to display tabs as two characters wide:

    def foo():
    ->if (long_named_function_that_returns_a_boolean() and
    ->....thing2() and thing3()):
    ->->do_stuff()

Basically, tabs get you several niceties with partially-dumb editors like emacs or vim. Indenting with spaces gives that all up and all you get in return is the ability to view code with notepad.exe.

maciejgryka2• 13 years ago

Ah crap, say it ain't so. Never noticed that before (in the "Comments" section):

    "You should use two spaces after a sentence-ending period."

lawnchair_larry• 13 years ago

I thought only technology-illiterate people made that error. Very surprised to see that.

rlpb9• 13 years ago

vim does it by default (eg. when rewrapping a paragraph). I only recently discovered the nojoinspaces option to turn it off. Before that I was removing the extra space by hand all the time.

smacktoward• 13 years ago

Or those of us who learned to type back in the days of Ye Typewriter.

cgore• 13 years ago

It's supposed to be an em-space, not two normal spaces, but that is hard to to in ASCII.

throw_away3• 13 years ago

Most code is read in fixed-width fonts. I don't see why this is controversial. The argument to use only one space after a sentence-ending period only makes sense when reading in a variable-width font as the width of the space is corrected when rendered (and two spaces over-corrects).

maciejgryka2• 13 years ago

I'm not sure I'd call it controversial, but it is definitely a small annoyance because of muscle memory.

Anyway, in the grand scheme of things this is really insignificant :) The fact that PEP8 exists at all is just one of the things making Python great!

eevee7• 13 years ago

Do any variable-width fonts actually do that? Looking at your comment, for example, the spaces after periods look the same width as those between words to my eye.

kps2• 13 years ago

No, extra space after a period is always in poor taste.

  Use a single word space between sentences. In the nineteenth century,
  which was a dark and inflationary age in typography and type design,
  many compositors were encouraged to stuff extra space between sentences.
  Generations of twentieth century typists were then taught to do the
  same, by hitting the spacebar twice after every period. Your typing
  as well asyour typesetting will benefit from unlearning this quaint
  Victorian habit. As a general rule, no more than a single space is
  required after a period, colon, or any other mark of punctuation.
  Larger spaces (e.g., en spaces) are *themselves* punctuation.

— Robert Bringhurst, The Elements of Typographic Style, 3rd Edition, §2.1.4

(Some people go as far as to recommend less than word space after a period or comma, since the blank area above the punctuation mark contributes to the total visual white space.)

cpeterso2• 13 years ago

My personal frustration with Python's coding standards is the combination of PascalCaseNames and snake_case_names. Rust has adopted the same coding style. :(

Plenty of C++ code uses UPPERCASE_SNAKE_CASE_NAMES for macros, but that doesn't seem so bad because macros are ugly and should be used less frequently than classes and functions. (I hope!)

eevee7• 13 years ago

Curious, why's that bother you? Different things should look different, and all. :) The alternative for class names is Camel_Snake, which will get you smacked in virtually any language.

Python code does tend to use UPPERCASE_SNAKE for "constants" as well, probably inherited from C (sometimes via Perl or Ruby).

cpeterso2• 13 years ago

Mixing the styles just feels inconsistent. The only language I know where Camel_Snake is used is Ada.

Shish2k• 13 years ago

What happens when you want to write a set of functions to handle a set of classes? Especially when you are given a class and want to figure out which handler to call dynamically - eg you have FooEvent, should the function be "handle_foo_event", "handle_FooEvent", "HandleFooEvent", or any of several other possibilities?

bentoner• 13 years ago

Here is a more readable diff: https://www.draftable.com/compare/9spTfcM

gcb0• 13 years ago

That looks nice, but do a quick comparisson:

go to the "Maximum Line Length" section. Now try to understand the changes wit the side-by-side one.

Now go to the original article link and do the same. It's much easier. At least for me.

penguindev3• 13 years ago

My one beef with the pep still is the one module per line recommendation:

"Imports should usually be on separate lines ... No: import sys, os"

Why not? I don't really spend a lot of time studying stdlib imports, nor need them on separate lines. Pyflakes will yell at me if something was not imported.

After all, one does (and is legal in the pep): from subprocess import Popen, PIPE, ... So how is that different conceptually than doing from stdlib import os, re, sys, ...

I certainly agree with separating stdlib, 3rd party libs, and your own modules by blank lines.. but why should usually trivial stdlib imports need so many lines?

eevee7• 13 years ago

If I see `from subprocess ...`, I know immediately that this module does something with subprocesses, and I don't much care about the rest of the line.

If I see `import os, sys, foo, bar...` then I don't get that information without actually inspecting the rest of the line.

The difference is minor, but skimming is valuable.

Siecje• 13 years ago

It would be nice to have a gofmt for python.

Or is there already a Ninja-IDE plugin that formats code?

coolsunglasses• 13 years ago

We do have a gofmt for Python.

pip install autopep8

Just pip search pep8 to see all the tooling.

It's not a "Ninja IDE" thingjobber, just a command line tool.

buster• 13 years ago

I really, really never understood why to indent with spaces, instead of tabs. I hoped this would've changed, but no...

I want to set for myself how much spaces represent an indentation, not someone else, it depends so much on your setup, the monitor, resolution, font settings, editor setup, if 2 spaces are fine, or 3 or 4...

PEP 8 Modernisation

Related Stories