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
>