Add style and formating files for Python. Format Python code.

[fruffy]

@vlstill @davidbolvansky

Adding a .pylintrc and a pytoml for style recommendations and formatting. Line-width is 100 because the majority of the files in this repository are written for a width of 100 characters. Yapf was chosen as formatter because it is configurable, as opposed to black, which enforces a particular style. Black is the formatter of choice because it is well maintained, by official Python maintainers, and requires little configuration.

[vlstill]

Should this be specified? It seems like something that will be hard to find once the build images are updated and newer minimal python is used.

[fruffy]

We can probably set it to 3.8 instead, the standard Ubuntu 20.04 version.

[fruffy]

@vlstill Any other comments?

[vlstill]

Thank you for this, having a consistent formatting is definitely step in the right direction and I think the formatting is generally good. However, I can see the following problems (all also marked in code):

• The comments inside multi-line lists are pushed right beyond the longest list element even if they are on otherwise-empty lines. This looks wrong and makes these comments hard to read.
• Formatting of long calls spreads the code over too many lines (especially if the arguments are short), but it might still be worth the consistency.
• The formatting of infix operator chains is suboptimal, but I'm afraid there is no good way to do this in Python.

[vlstill]

This one is the most readable due to the header name being split from its content, but I don't see a good alternative, as both

        exp_pkt = Ether(dst="11:11:11:11:11:11") / \
            MPLS(label=20, cos=5, s=1, ttl=64) / \
            testutils.simple_ip_only_packet(ip_dst="192.168.1.1")

and

        exp_pkt = (Ether(dst="11:11:11:11:11:11") /
            MPLS(label=20, cos=5, s=1, ttl=64) /
            testutils.simple_ip_only_packet(ip_dst="192.168.1.1"))

look somewhat weird. For me, the last one might be acceptable and so is the one you have chosen. I'd probably avoid the \ version due to weird combination with /.

[fruffy]

Switching to black, which has a very uncompromising code style. Black is maintained by Łukasz Langa, who maintains the Python packages. This should give us a rather canonical Python style.

The reason I previously chose not to use that was because of the multi-line inline indentation alignment. However, since we have abandoned that concept, we should be able to use black without issues.

[fruffy]

@vlstill Mind giving this another review? I switched to black with some tweaks and the formatting seems sound.

[qobilidop]

I happen to see this PR while working on updating one of the Python scripts, and have one minor suggestion. I wonder if isort could be used together with black to sort imports besides formatting? isort integrates with black easily so this should be straightforward.

[fruffy]

I happen to see this PR while working on updating one of the Python scripts, and have one minor suggestion. I wonder if isort could be used together with black to sort imports besides formatting? isort integrates with black easily so this should be straightforward.

Done.

[fruffy]

@mbudiu-vmw Mind giving this a review?

[mihaibudiu]

I don't really see any improvement in the readability of the Python code.
I am not sure what these tools bring. If they found some bugs I would be more convinced.

[fruffy]

I don't really see any improvement in the readability of the Python code. I am not sure what these tools bring. If they found some bugs I would be more convinced.

This PR came up because of a request. These are the benefits I see:

1. The configurations essentially enforce the code preferences described in human prose in guides like this one.
2. Applying autoformatting becomes easier because, once the style is enforced across the entire project, one does not have to worry about using a formatter when writing code. With that you do not produce diffs that are unnecessary. This also means you do not have to deal with manual code formatting. The configuration also makes sure everyone uses the same formatter for this particular project.
3. PR reviews become easier because the linters take care of arguments around style.
4. Code style is consistent across the entire project, which does help readability (even though what can be considered readable code may be up to debate).

We could also try to apply linters that find bugs. For example, mypy likely would find many inconsistencies in our Python code. But instrumenting those is laborious and the linters are more opinionated.