Q000 Double quotes found but single quotes preferred

[cidrblock]

I think this comes via wemake:

https://wemake-python-stylegui.de/en/0.2.0/_pages/violations/index.html

        (NavigatorVolumeMount("/foo", "/bar", "z"), "/foo:/bar:z"),

from tests/unit/configuration_subsystem/test_navigator_post_processor.py

in #738

Here to talk about, haven't really looked at it, but there were a ton and it got my attention

[ssbarnea]

This rule is BS, black already decided to use double quotes and we require that on navigator and other projects. I do not want to debate about that. What is next, debating tabs vs spaces? ;)

[webknjaz]

Well, black's opinion is BS, so let's not drop it without debate.

[ssbarnea]

Let me give some insights here regarding why I consider the idea of using Q000 more of a can of worms:

• Black was already inside the repository when the Q000 was introduced alongside few hundred other rules as part of the we-make-linting-a-nightmare plugin bundle, removing it just restoring the status-quo, not a change of workflows.
• About 3-4 years ago, when I started to use black I wondered why black made the decision to stick to double quotes instead of single quotes. After reading few very hot issues on github I realised that they made the right call. Basically single quote is quite common as part of a sentence on english language, so is less likely to need escapes if you go for double quotes. For few months I was really appalled about that decision, it took me some time to get used to it and understand that having a single standard is far better than multiple, one of the reasons why black is almost not configurable, avoiding divergence.
• We have 15+ community projects which already use black and I see zero chances to get support from community to switch their codebase to something else. The idea that we will have divergent rules in our repos is clearly not appealing too.
• The main reason why I was a black supporter was because it removed the subjectivity from code reviews. The main benefit was that I no longer have to see reviewers telling the reviewed to reformat his code to their own preferences. The tool is not human and that is wonderful, it can also fix stuff automatically and people can focus on important things, not philosophy.

I do not want to see more reviews where a human is telling me to write the code differently because it looks better from their point of view.

I am even afraid to share the link to this discussion our other team members as I want to avoid alienating them around the linters. I bet they want to focus on implementing cool features or fixing bugs far more than engaging in draining discussions about code formatting.

As some of the team members are already in PTO this will have to happen in January. I am not looking forward about an exhausting meeting, hopefully we could sort this subject offline.

[webknjaz]

Looks the "nightmare" reference is just an excuse not to care about the quality which aligns greatly with what black does but does not align with wanting a great code quality and freedom to express what the code means in many cases. And that is a deal-breaker. I've told you many times that I support not requesting the code style changes in PRs and I specifically try to avoid this. But wanting to see readable code is orthogonal to its formatting — sometimes it aligns and sometimes this tool of repression just doesn't allow for writing code in a readable manner. This is why this oppressive tool has driven me away from a number of projects. There are certain tools that can implement similar formatting with less friction, separating the controversial discussions from things people can agree on.
As for Q000, it mustn't be dropped but it's possible to change its configuration for the time being to match the current state.

[ssbarnea]

Considering that just earlier today I got a very constructive comment about formatting on a repository that happened to already have the yamllint enabled, I am not sure what to say about removing the human formatting comments from reviews:

Was this comment adding any value to the review? I see it as nitpicking. I personally do not think that value of review is measured in number of comments/problems you can make to them. I often spot many minor problems but I refrain from mentioning them. My goal is not to make the other party to write code the same way I would write it.

[webknjaz]

Here to talk about, haven't really looked at it, but there were a ton and it got my attention

TL;DR — it's black's fault. For as long as it poisons our development workflows, it'll cause such conflicts.

FWIW that linter plugin can be controlled by an inline-quotes setting in .flake8.

[cidrblock]

This is covered by adding inline-quotes to the flake8 configuration file as seen here:

#845