[Python-ideas] PEP 8 update on line length

[Abe Dillon]

[simon.bordeyne]

> I find that 100 to 120 characters is ideal as far as line length goes.

Your finding goes against a long history of people attempting to present
text in the most readable way possible.
AFIK, the human fovea hasn't grown much larger in recent years.

[simon.bordeyne]

>  On top of that, it's not uncommon to reach 6, even 7 indentation levels.

It should be pretty uncommon. You might want to re-think your coding style
if you're regularly writing code that's so deeply indented.
A good trick is to use helper functions:

#instead of this
if condition:
    ...code

#do this
if condition:
    handle_it()

[simon.bordeyne]

> All it takes is a loop in a loop (looping through an array for instance),
> a condition and all of that inside a class' method. Just in that example,
> which is a very common occurence, an doesn't warrant refactoring, there is
> 5 indentation level, eg a quarter of the recommended line length.

You should check out the itertools library and possibly the toolz package.
I find it's often pretty simple to collapse nested loops in python:

for n, element in enumerate(chain(*array)):
    r, c = divmod(n, len(array[0]))  # if you need the indexes
    if condition(element): do_something(element) # this follows the
one-line one-thought rule over PEP8


On Tue, Feb 19, 2019 at 8:08 AM simon.bordeyne <simon.bordeyne at gmail.com>
wrote:

> I find that 100 to 120 characters is ideal as far as line length goes. In
> my opinion, splitting lines is much worse in terms of cognitive burden than
> just a longer line. On top of that, it's not uncommon to reach 6, even 7
> indentation levels. All it takes is a loop in a loop (looping through an
> array for instance), a condition and all of that inside a class' method.
> Just in that example, which is a very common occurence, an doesn't warrant
> refactoring, there is 5 indentation level, eg a quarter of the recommended
> line length.
>
> Defining decorators also goes up there in terms of number of indents by
> the way.
>
> As far as monitor size goes, I agree that on a laptop is not ideal for
> 100+ characters per line if you want two pieces of code side by side. And,
> fyi, I work on a 23" monitor at home and on a 15.6" monitor on the go. Both
> are perfectly fine with 100 characters a line.
>
> A good middle ground would be to enforce customization of that rule in the
> most used python linters. A simple setting to set the number of characters
> before a linting warning occurs would be acceptable.
>
>
>
> Envoyé depuis mon smartphone Samsung Galaxy.
>
> -------- Message d'origine --------
> De : David Mertz <mertz at gnosis.cx>
> Date : 19/02/2019 07:28 (GMT+01:00)
> À : Anders Hovmöller <boxed at killingar.net>
> Cc : Simon <simon.bordeyne at gmail.com>, python-ideas <
> python-ideas at python.org>
> Objet : Re: [Python-ideas] PEP 8 update on line length
>
> 60, or 68, or 80 characters, is not per se a cognitive limit. Yes, sure
> whitespace counts much less towards that burden than do regular characters.
> And to a significant degrees, punctuation vs. letters vs. numbers matter.
> And sure familiar words such as keywords scan a bit easier than unfamiliar
> names of variables. And so on.
>
> But 80 characters in general is already too wide most of the time. 65 is a
> better goal as a rule of thumb, with 80 already being for exceptionally
> long lines. Python keywords are already short, there's not much improvement
> to be had there. Saving two characters for acryptic WHL isn't better than
> the word 'while', for example.
>
> Pretty much the only time my code how's more than 80 characters is when it
> includes string literally that occupy a large chunk of the width. But if
> that 50 character string is the last argument of a function call, the
> reader can mostly stop scanning at it's beginning, so it's not terrible.
> When I have many keyword arguments, I break them into multiple physical
> lines using parents too continue the logical line. Or if I have complex
> compound conditions, I give the subclauses short but descriptive names
> before the if/elif.
>
> On Tue, Feb 19, 2019, 1:11 AM Anders Hovmöller <boxed at killingar.net wrote:
>
>>
>>
>> > On 19 Feb 2019, at 05:48, David Mertz <mertz at gnosis.cx> wrote:
>> >
>> > You either have much better eyes to read tiny fonts than I do, or maybe
>> a much larger monitor (it's hard for me to fit a 30"" monitor in my laptop
>> bag).
>> >
>> > But that's not even the real issue. If the characters were in giant
>> letters on billboards, I still would never want more than 80 of them on a
>> line (well, rarely, I violate PEP 8 sometimes). Centuries if not millennia
>> of experience with writing show that cognitive burden goes up
>> exponentially, not linearly, as lines get to be more than about 60
>> characters.
>>
>> If that is the issue then we should be talking about non-space
>> characters, not a 68 column limit right? No way does 40 spaces due to
>> indent count towards the cognitive burden :)
>>
>> Also, if the cognitive burden is the issue then we should talk about
>> short forms for keyword arguments again. The way the 68 column limit works
>> in practice is that people avoid keyword arguments because of line length,
>> plus the issues already mentioned.
>>
>> / Anders
>
> _______________________________________________
> 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/c8ee04f6/attachment-0001.html>