Re: [PATCH v7 06/10] iotests: limit line length to 79 chars

[John Snow <jsnow@redhat.com>]

On 3/5/20 6:55 AM, Kevin Wolf wrote:
> Am 05.03.2020 um 00:14 hat John Snow geschrieben:
>>
>>
>> On 3/4/20 4:58 PM, Philippe Mathieu-Daudé wrote:
> 
> Adding back the context:
> 
>> -        sys.stderr.write('qemu-img received signal %i: %s\n' % (-exitcode, ' '.join(qemu_img_args + list(args))))
>> +        sys.stderr.write('qemu-img received signal %i: %s\n' % (
>> +            -exitcode, ' '.join(qemu_img_args + list(args))))
> 
>>> Do we want to indent Python like C and align argument below opening
>>> parenthesis? Except when using sys.stderr.write() you seem to do it.
>>
>> This isn't an argument to write, it's an argument to the format string,
>> so I will say "no."
> 
> The argument to write() is an expression. This expression contains the %
> operator with both of its operands. It's still fully within the
> parentheses of write(), so I think Philippe's question is valid.
> 
>> For *where* I've placed the line break, this is the correct indentation.
>> emacs's python mode will settle on this indent, too.
>>
>> https://python.org/dev/peps/pep-0008/#indentation
> 
> The PEP-8 examples are not nested, so it's not completely clear. I
> wonder if hanging indents wouldn't actually mean the following because
> if you line wrap an argument list (which contains the whole %
> expression), you're supposed to have nothing else on the line of the
> opening parenthesis:
> 
>     sys.stderr.write(
>         'qemu-img received signal %i: %s\n'
>         % (-exitcode, ' '.join(qemu_img_args + list(args))))
> 

This is fine too.

> But anyway, I think the question is more whether we want to use hanging
> indents at all (or at least if we want to use it even in cases where the
> opening parenthesis isn't already at like 70 characters) when we're
> avoiding it in our C coding style.
> 
> There's no technical answer to this, it's a question of our preferences.
> 

Maybe it is ambiguous. Long lines are just ugly everywhere.

>> (If anyone quotes Guido's belittling comment in this email, I will
>> become cross.)
>>
>>
>> But there are other places to put the line break. This is also
>> technically valid:
>>
>> sys.stderr.write('qemu-img received signal %i: %s\n'
>>                  % (-exitcode, ' '.join(qemu_img_args + list(args))))
>>
>> And so is this:
>>
>>     sys.stderr.write('qemu-img received signal %i: %s\n' %
>>                      (-exitcode, ' '.join(qemu_img_args + list(args))))
> 
> PEP-8 suggests the former, but allows both styles:
> 
> https://www.python.org/dev/peps/pep-0008/#should-a-line-break-before-or-after-a-binary-operator
> 

So in summary:

- Avoid nested hanging indents from format operators
- Use a line break before the % format operator.
- OPTIONALLY(?), use a hanging indent for the entire format string to
reduce nesting depth.


e.g., either this form:
(using a line break before the binary operator and nesting to the
argument level)

write('hello %s'
      % (world,))


or optionally this form if it buys you a little more room:
(using a hanging indent of 4 spaces and nesting arguments at that level)

write(
    'hello %s'
    % ('world',))


but not ever this form:
(Using a hanging indent of 4 spaces from the opening paren of the format
operand)

write('hello %s' % (
    'world',))



yea/nea?

(Kevin, Philippe, Markus, Max)

>> (And so would be any other number of rewrites to use format codes,
>> f-strings, or temporary variables to otherwise reduce the length of the
>> line.)
>>
>> I will reluctantly admit that wrapping to 79 columns is useful in some
>> contexts. The beauty of line continuations is something I have little
>> desire to litigate, though.
>>
>> If there's some consensus on the true and beautiful way to do it, I will
>> oblige -- but the thought of spinning more iterations until we find a
>> color swatch we like is an unpleasant one.
> 
> I'll accept any colour for the bikeshed, as long as it's green. ;-)
> 
> Kevin
>