
PEP 8 Modernisation - tristaneuan
http://hg.python.org/peps/rev/fb24c80e9afb
======
jowiar

        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.

~~~
memset
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?

~~~
coldtea
> _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.

~~~
qu4z-2
Between ^Z, :<range>!, :grep, make, and other tools, vim has great
compatibility with my system, thanks :)

~~~
coldtea
Do it have an in-editor terminal?

An in-editor debugger?

Does it offer a REPL?

Does it work with your build system and your SCM system without some ho-hum
third party plugins?

~~~
qu4z-2
In-editor terminal? ^Z or :shell (Asking for an in-editor terminal makes about
as much sense as my whinging that Eclipse doesn't have an in-terminal editor)

In-editor debugger? I admit this is less than ideal.

A REPL? Languages suited to REPLs have REPLs, and a lot of them support SLIME,
allowing me to interact with the REPL from vim. For everything else there's
tmux.

Build system? :make and errorformat

SCM integration? ^Z. Or fugitive I guess. (a third party plugin, yes. But if
you think it's ho-hum, you probably haven't used it).

------
publicfig
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.

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

[https://gist.github.com/radiosilence/6133713](https://gist.github.com/radiosilence/6133713)

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

~~~
gsnedders
Either is acceptable per PEP 8.

~~~
antihero
Oh, neat! I don't have to feel dirty now.

------
raverbashing
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)

~~~
cjensen
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.

~~~
adamtj
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.

~~~
eevee
I prefer not to have to juggle invisible characters when editing plain text.

~~~
Qantourisc
Tabs are visible in my editor. And so are the spaces at the end of a line it's
sweet: :set listchars=tab:\|·,trail:·

~~~
eevee
Isn't it a little self-defeating to make indentation visible? The whole idea
is that it's easy to pick out blocks by the shape of the left margin, i.e.,
where the first visible character is.

If your indentation scheme only works when configuring your editor to mark
whitespace, we might as well go back to MUMPS and indent with dots.

------
kbenson
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
The Yes/No tags are not code. The PEP is not advocating their style for all
text documents.

~~~
kbenson
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_.

------
bentoner
Here is a more readable diff:
[https://www.draftable.com/compare/9spTfcM](https://www.draftable.com/compare/9spTfcM)

~~~
gcb0
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.

------
penguindev
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?

~~~
eevee
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.

------
maciejgryka
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."

~~~
throw_away
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).

~~~
eevee
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.

~~~
jedberg
The em space fell out of favor when HTML got popular, because HTML renderers
(ie. your browser) will strip extra spaces. So when looking at a web page,
there actually is no difference between one and one hundred spaces (or two).

------
buster
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...

------
cpeterso
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!)

~~~
eevee
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).

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

------
Siecje
It would be nice to have a gofmt for python.

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

~~~
coolsunglasses
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.

