Re: [PATCH net-next v1 4/6] tools/net/ynl: Add binary and pad support to structs for tc

[Donald Hunter <donald.hunter@gmail.com>]

Jakub Kicinski <kuba@kernel.org> writes:

> On Thu, 30 Nov 2023 21:49:56 +0000 Donald Hunter wrote:
>> The tc netlink-raw family needs binary and pad types for several
>> qopt C structs. Add support for them to ynl.
>
> Nice reuse of the concept of "pad", I don't see why not:
>
> Reviewed-by: Jakub Kicinski <kuba@kernel.org>
>
>> +                value = msg.raw[offset:offset+m.len]
>
> What does Python style guide say about spaces around '+' here?
> I tend to use C style, no idea if it's right.

The relevant section seems to be this:

  However, in a slice the colon acts like a binary operator, and should
  have equal amounts on either side (treating it as the operator with
  the lowest priority). In an extended slice, both colons must have the
  same amount of spacing applied. Exception: when a slice parameter is
  omitted, the space is omitted:

  # Correct:
  ham[1:9], ham[1:9:3], ham[:9:3], ham[1::3], ham[1:9:]
  ham[lower:upper], ham[lower:upper:], ham[lower::step]
  ham[lower+offset : upper+offset]
  ham[: upper_fn(x) : step_fn(x)], ham[:: step_fn(x)]
  ham[lower + offset : upper + offset]

  # Wrong:
  ham[lower + offset:upper + offset]
  ham[1: 9], ham[1 :9], ham[1:9 :3]
  ham[lower : : step]
  ham[ : upper]

On that basis I could change it to:

  (a) value = msg.raw[offset : offset+m.len]

or:

  (b) value = msg.raw[offset : offset + m.len]

But the existing convention in the code is a mix of these styles:

  raw[offset:offset + 4]
  raw[offset:offset+m['len']]

Happy to go with whatever preference, though maximising whitespace per
(b) follows python style _and_ C style?

Also happy to make it consistent across the file (in a separate patch)?