[Python-ideas] PEP 8 update on line length

[Christopher Barker]

On Wed, Feb 20, 2019 at 10:57 PM Abe Dillon <abedillon at gmail.com> wrote:

> I wish you would have watched the video I linked
> <https://www.youtube.com/watch?v=B3b4tremI5o&t=7m45s>
>

that is an hour and 7 minute video! And I did watch some of it, and do
agree with much of it.

By the way, everyone should watch one of Jack Diederich's "naming things
once videos as well:

https://www.youtube.com/watch?v=hZ7hgYKKnF0



>  but in the context of code running off the edge of a window,
>

I never said anything about running off the edge of the window -- if you
put all your parameters on their own line, and don't use insanely long
names, that will not be an issue. Keeping it to 72 chars is virtually never
a problem.


> having the argument list hidden out there
>

nothing hidden about it --it's exactly where a single argument would be --
does anyone advocate putting a single parameter or argument on the next
line?

But my core point really was these are all matter of opiniion, and it's a
godo thing that PEP 8 allows some variation.

> This puts the parameter definitions over on the right, after the function
>> name, where they belong
>
>
> According to whom?
>

According to me, of course. But it is wehre a single parameter would be,
yes?


> [Christopher Baker]
>
>> if you HAVE to put it off to the left for I don't know why, at least put
>> some extra space in there:
>> def a_function_with_lots_of_params(
>>         param1,
>>         param2,
>>         kwarg1=something,
>>         kwarg2=something_else):
>>     now_a_line_of_code = this_thing()
>> The parameters are still in an odd place, but at least it's clear where
>> the body of the function begins.
>
>
> If you'd seen my other replies in this very thread, you'd see that's
> exactly the style I use.
>

I've lost track of who advocates what style, but I was responding to
someone that specifically advocated one level of indentation -- which is
really the worst option.

[Christopher Baker]
>
>> well, that is an issue that I do face, but I blame it on my crappy tools
>> :-)
>
>
> I consider it a good thing that your tools don't facilitate bad coding
> style ;)
>

mostly they don't facilitate any of these styles in this context (I've been
meaning to write a plugin for sublime that does, but haven't gotten around
to it ). But the point is that handling indenting is really something the
tools should do for you -- choosing a style for "ease of refactoring"
should be pointless.


> This is just more Stockholm syndrome.
>

honestly, I haven't chooses this style due to having been forced (or even
encouraged) to use it -- I spend more time re-aligning code to make it the
way I want it -- so no, I"ve come on this 'cuse it fits my brain better.


> Nowhere else will you see people consider cramming valuable information
> off into the right margin with arbitrary indentation "good design".
>

It's not the margin, and it's not arbitrary.


> You won't see it in prose. You won't see it in mathematical notation. You
> won't see it anywhere else.
>

Actually, I"ve seen in it math, where you have an "array" of equations, and
> tabular information with columns on the right being important is not the
> least bit rare.
> > But if you are going to do it, for the love of god, use more than four
> > spaces! four spaces is one indentation, one indentation is how a code
> > block is delineated in Python -- this is NOT a code block. It should not
> > look like one.
>         I feel the complete opposite.  "One indentation" is the only unit
> in
> multiples of which anything should ever be indented.  Using arbitrary
> "indentation" to visually line things up is horrible.  Everything gets
> indented by an integer number of indentation levels.


OK, then use two indentation levels for the parameter stack -- just don't
use one -- that really is the worst option -- one indentation has real
meaning in code.

-CHB

-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20190220/4fbe57ef/attachment-0001.html>