[Python-ideas] PEP 8 update on line length

[Abe Dillon]

First of all, thank you so much for taking the time to do some actual
analysis!
I only have one thing to add:

[Paul Ferrell]

> 3 - function calls
> Function calls, even with the arguments put one per line, often exceed 80
> (and sometimes 100) character limit. The issue tends to be a combination of
> tabbing, kwarg names, and the context in which all of this is used. It's
> often unavoidable.
> variable = some_class.method(argument=value,
>                                                    argument2=value)


This reminds me of a bit that shows up often in Kevlin Henney's talks
<https://www.youtube.com/watch?v=B3b4tremI5o&t=7m45s>.

A better way to list arguments is only one indentation level above the
current:

variable = some_class.method(
    argument=value,
    argument2=value)

Trying to match the indentation of the opening line is less readable and
less robust to refactoring:

variable = some_class.method(argument=value,
                             argument2=value)

var = cls.method(argument=value,
                             argument2=value)

On Wed, Feb 20, 2019 at 4:52 PM Paul Ferrell <pflarr at gmail.com> wrote:

> Opinion first - I don't see a need to change PEP 8. I recommend 100 char
> width for Python, which is acceptable under PEP 8 anyway. I think the real
> limit should be around 70 characters per line, not including leading
> white-space, but I realize that's impractical.
>
> I work mostly at 100 character line width, and the question of line width
> came up for me recently.  Otherwise, I follow PEP 8. I want to see where,
> and why I exceed 79 chars, so I dove into a decently sized module file of
> mine and tallied the results. This is what I found.
>
> 563 total lines
> 448 non-blank lines
>
> For the non-blank lines:
> 49.6 characters per line on average
> 36.7 non-leading-whitespace characters per line
> 13.1 leading spaces per line on average
> 15.5% of lines exceeded 79 chars.
>
> The 69 lines that exceeded 79 characters fell into the following
> categories, listed according to how annoying they would be to fix.
>
> 1 - with statements
> I have a with statement that contains two context managers "with
> open(blah) as b, open(foo) as f:". There isn't a really good way to wrap
> this without adding another with statement or a backslash.
>
> 3 - function calls
> Function calls, even with the arguments put one per line, often exceed 80
> (and sometimes 100) character limit. The issue tends to be a combination of
> tabbing, kwarg names, and the context in which all of this is used. It's
> often unavoidable.
> variable = some_class.method(argument=value,
>                                                    argument2=value)
>
> 5 - Overly deep logic
> There were a couple of blocks of code that should have been pushed into
> separate methods/functions. I do occasionally run into issues where there
> simply isn't room (in 79 chars) for the logic required, and that logic
> can't reasonably be separated out.
>
> 8 - Format calls
> While I love the new format syntax, I almost always end up moving the
> format call to a new line with 4 spaces of extra indentation. These were
> instances of when I didn't.
>
> 21 - Comments
> There's plenty of space for readable comments in most cases. Under several
> nested scopes, however, the space gets pretty tight. Those extra 20 chars
> go a long way.
>
> 12 - Strings
> Like comments, having a few extra chars for strings (mostly exception
> messages in this case) goes a long way when even moderately nested.
>
> 2 - Chained conditionals
> if A and B and C
> Should have been:
> if (A and
>         B and
>         C):
>
> 16 - Doc strings
> These are easily fixable with no change in readability, and rarely have
> issues with padding.
>
> On Wed, Feb 20, 2019 at 12:57 PM Chris Angelico <rosuav at gmail.com> wrote:
>
>> On Thu, Feb 21, 2019 at 6:48 AM Jonathan Fine <jfine2358 at gmail.com>
>> wrote:
>> > Here's a suggestion, at least for people projects that use black.py
>> > (such as Samuel's). It is to use black.py with a line-length of say 80
>> > characters for code that is saved in version control. And when editing
>> > code, use whatever line-length that happens to suit the tools you are
>> > using.
>> >
>> > Indeed, like a word-processor, one could use black.py to 'line-wrap'
>> > the Python code to what is the current width of the editor window.
>>
>> From my experience (granted, I work heavily with students, so maybe
>> it's different if everyone involved in the project has 5+ or 10+ years
>> coding), autoformatters are a blight. They take a simple, easy-to-find
>> missed parenthesis, and completely obscure it by reindenting the code
>> until it finds something unrelated that seems to close it. The
>> indentation in the code of even a novice programmer is valuable
>> information about *programmer intent*, and throwing that away
>> automatically as part of checking in code (or, worse, every time you
>> save the file) is a bad idea. Easy bugs become hard.
>>
>> Of course, if you assume that everything in your code is perfect, then
>> by all means, reformat it however you like. If you're 100% confident
>> that nobody writes any buggy code, then the formatting doesn't matter,
>> and you can display it in whichever way looks prettiest. But if you
>> appreciate ways of discovering bugs more easily, preserve everything
>> that represents the programmer's intention.
>>
>> ChrisA
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> Paul Ferrell
> pflarr at gmail.com
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20190220/dd51ad6b/attachment.html>