Increase the max line length for pep8speaks to 120 characters

[cmihai]

Based on the example config from https://pep8speaks.com/.

Rationale: The default PEP8 line length is sometimes not enough for expressivity. See also https://medium.com/@drb/pep-8-beautiful-code-and-the-tyranny-of-guidelines-f96499f5ac17 .

[Gnappuraz]

We are in 2019, 120 chars I think would fit even in most cellphones... utACK dbed8b9

[scravy]

Concept ACK dbed8b9

[AM5800]

ACK dbed8b9
Existing codebase does not really fit into 79 chars. So enforcing 79 chars will only make our life harder

[cornelius]

Having a more flexible line limit is good from my point of view. I would still strive for 79 character max lines, but this often is hard to achieve, so always having a warning when it's a bit more doesn't feel too helpful to me. 120 characters sounds like a reasonable compromise which is also not uncommon to be used by other people.

[AM5800]

Although this PR already has 4 approvals, I would like to ask not to commit it immediately after travis finishes. Because this topic is very hot and I believe people should have some time to express their concerns. So let's merge it in the evening or something

[frolosofsky]

My concern is not relevant to this PR, but I missed a point we started using this bot. I personally do not like such things because they spam into the comments with no real benefit, because their reports are not something we will discuss, and it converts comments from discussion to developer log or alike. In my opinion, the pep8 checks should go to the Travis linter phase instead.

[cornelius]

My concern is not relevant to this PR, but I missed a point we started using this bot. I personally do not like such things because they spam into the comments with no real benefit, because their reports are not something we will discuss, and it converts comments from discussion to developer log or alike. In my opinion, the pep8 checks should go to the Travis linter phase instead.

What in my view works best is a tool which actually comments on the code where the issues are. Something like https://houndci.com/. This is more like a normal review discussion than the one comment where pep8speaks collects all issues. If it is set up in a way that it only comments on the style issues we actually want to fix, then the bot takes the burden of nitpicking, which I think is a real benefit.

[cmihai]

In my opinion, the pep8 checks should go to the Travis linter phase instead.

That is already the case, but failing the lint check doesn't currently stop the build. I've created issue #1054 for it.

[scravy]

I added pep8speaks which is an App which this pull request targets the configuration for it.

We have been thinking about this for some time already. The idea is that linting in travis might fail the build but could happen in parallel instead. Ideally you would get a report like "unit tests pass", "functional tests pass", "linting fails". This also eases review.

The app is not a mandatory check but adds one comment which is continuously updated and it only targets the touched lines, which is quite nice and would require a lot of effort in travis config otherwise.

[cornelius]

Also see issue dtr-org/unit-e-project#76

[kostyantyn]

ACK dbed8b9

If we keep this service, I think it's reasonable to have 120-character lines for python as this is how currently our tests try to adhere.

[castarco]

ACK dbed8b9

I do prefer 80 characters, but it's more important for me to have a limit that everyone respects, and it seems that having 80 characters could motivate people to disable this check... so 120 is OK for me.