If I could amend PEP 8

All good rules started by nobody else using it. Though, in this case, at least three people discovered that rule independently.

I do. People I work with do. People I mentor do.

A lot of people use it. That's how I was taught to write Python and that's how I wrote it in several different companies. At my current job we use double-quotes for everything though (for some reason).

ITYM: [$i|[$n|[$d|[$e|[$e|[$d]]]]]].

Yes "Indeed".

> * 3 side/side buffers is arbitrary, (it would be 2 on a small laptop display) *

It's about 1/3 of my 13" 2013 Macbook Air - the other 2/3 is usually a browser.

It's also not even about how much horizontal space there is for any reason - it just scans better if you keep it narrower.

You "don't" need to go over 80 chars.

But it's stupid to break a line like this in two

stuff.do_something_funny(abc, def, ghi)

when the limit is reached at the 3rd parameter (or worse, at the parenthesis)

By that reasoning you could almost say 'find an example where you had to go over [insert arbitrary number between 50 and 100 or so]'. If the number if low enough or my screen is wide enough I could fit 4 text editor panes next to each other :] Any code could probably be broken up to match that as well.

Don't get me wrong, I personally think 80 is a fine number and it's what I use myself. But making things like this hard rules for what basically are arbitrary reasons (e.g. depending on screen resolution) doesn't seem right in my book. I'm seriously not even considering doing something about a line if it's 81 characters.

Not python, but in Java, identifiers can get quite long. e.g.: "localizableRUNTIME_MODELER_PORTNAME_SERVICENAME_NAMESPACE_MISMATCH" is the longest at 66 characters.

As for python, some fancy list comprehensions get rather long rather quickly. Especially if itertools are involved as you izip, etc. Or using useful variable names (i.e. not 'fcnt', 'tcnt') while destructuring as in this example from pyspark/mllib:

(failure_count, test_count) = doctest.testmod(globs=globs, optionflags=doctest.ELLIPSIS)

I adapted your grep to:

  find . -name '*.py' | xargs grep -n '^ *.\{80\}'

So leading indentation doesn't mess with the results.

Try this on the python source itself and you'll find a lot of perfectly reasonable examples. One problem is that in a method, your first meaningful indent is actually three (12 spaces in) - two are eaten up in declaration ceremony. In a language with delimiters instead of significant whitespace you could just fiddle with the convention - for instance, you could decide that you're just not going to give up a full indent for toplevel class members. This isn't an option in Python.

i just love that i had never thought of trying to find lines of code of a certain length this way and you probably just wrote it without a second thought.

hn is such a cool place. :)

Well if your text editor is not powerful enough, maybe it's a problem.

> Because when you refactor the function/class name, it's never just one region

... the region is whatever you say it is:

  (mark-whole-buffer)
  (indent-region)

Or, most likely, something like: C-x h TAB

I don't think that's particularly onerous.

It's only a few lines of elisp to visit all the files in a tree and automatically format them. That said, it would probably be more sensible to modify whatever refactoring tool to be indentation aware, if it isn't already. Again, that's easy to do with elisp.

I believe it will be:

    def very_long_function_name(
        arg_one,
        arg_two,
        arg_three,
        arg_four
    ):

It's consistent and doesn't require spaces so it lets you use tabs to let the reader choose its indentation size.

The same thing basically, sibling comment has it.

`):` always either on the first (and only) line or the last line, which ensures it either over-runs the function body indention level, or falls short:

    def a():
        pass

    def b(
    ):
        pass

Use the same principle as the last of OJFord's examples:

  def very_long_function_name(
      arg_one,
      arg_two,
      arg_three,
      arg_four
  ):
      ...

The nice thing here is that the close parenthesis separates the parameters from the function body, without having to do anything like double-indenting.

What's interesting to me is to try to understand why people are attracted to the column-aligned style even when it has so many problems. I think it comes directly from being unwilling to put spaces inside the parentheses when it's a one-liner:

  long_function_name(var_one, var_two, var_three, var_four)

If you find that line getting too long and want to break it into multiple lines, it's natural that the first thing you do is to turn spaces into newlines:

  long_function_name(var_one,
  var_two,
  var_three,
  var_four)

Well that's ugly, so what can we do with it? A few people indent the arguments after the first one:

  long_function_name(var_one,
      var_two,
      var_three,
      var_four)

That doesn't make much sense; why is the first argument not lined up with the rest? So the next natural thing to try is the column aligned style:

  long_function_name(var_one,
                     var_two,
                     var_three,
                     var_four)

And now you have the problems that brings; fiddly maintenance and excessive line lengths.

But what if you cultivate a style of putting spaces inside the parens, like this:

  long_function_name( var_one, var_two, var_three, var_four )

Now when you have to break it into multiple lines, the natural place to start is again to turn the spaces into newlines:

  long_function_name(
  var_one,
  var_two,
  var_three,
  var_four
  )

and from here it's simple to add some indentation:

  long_function_name(
      var_one,
      var_two,
      var_three,
      var_four
  )

What I haven't figured out is why so many programmers are opposed to putting spaces inside the parentheses. Not only does this lead to better practices when you switch back and forth between single line and multiline styles, but it's more logical too. In this example, the open paren "belongs" to the function call, not to the first argument. Why should the arguments get spaces between then, but the first argument is a special case, directly attached to the function name?

In fact, PEP8, if you take it as gospel, forbids spaces inside the parentheses. But as is common with these things, it gives no reason or rationale for this. It's simply listed as a "pet peeve".

I've seen a few style guides where the authors realized it would be nice to have some whitespace between the function name and first argument, but just couldn't bring themselves to try putting the space inside the parentheses, so they put it outside:

  long_function_name (var_one, var_two, var_three, var_four)

A lot of Unity C# code is written like this, because it's MonoDevelop's default style. It's not terrible when you see a simple example, but it gets pretty bad when there are nested functions:

  DoSomething (Foo (x), Bar (y))

The whitespace here has very little to do with the actual structure of the code. Contrast this with:

  DoSomething( Foo(x), Bar(y) )

Now the things that belong most closely together are visually connected, and spaces separate the things that are less connected. I didn't put spaces inside the parens for the inner functions, only the outer one, to help emphasize what is connected to what.