Single quotes option

[bofm]

Hi! Although Black now prefers doubles, can we have an option to keep single quotes? Forcing double quotes would make this great project unusable for many users who picked the rule of using single quotes.

Operating system: MacOS
Python version: 3.6
Black version: 18.4a0
Does also happen on master: yes

[gaggle]

I'm not a maintainer just an interested user, I respectfully voted down because I think black's power is to annihilate all these small discussions forever. Out of curiosity are there objective reasons that you need to stick with single-quotes?

[bofm]

are there objective reasons that you need to stick with single-quotes?

It is an approved code style I have to use at work. There are millions of lines of code with single quotes in the existing code base which are not going to be reformatted. I believe this is also the case for other people.

[ambv]

Please discuss the approved code style at work, Black's documentation is using several arguments as to why double quotes are preferred.

If you have strong reasons to prefer single quotes, list them here. "Approved code style" is not a reason alone.

[bofm]

The reasons to add single quotes options:

• Black is unusable when contributing to an existing project written with single quotes
• Python official documentation uses single quotes in code examples
• default repr() produces single-quoted string literals for most standard types (dict, list, tuple, str, bytes, namedtuple, etc)
• many popular projects and their docs use single quotes
• PEP proposals mostly use single quotes in code examples
• Guido used single quotes in his latest commits on Github

Let me emphasize - the point is that restricting the quotes variants to only double quotes makes this cool project unusable for a big part of Python programmers.

[ambv]

All your reasons can be summarized like this: "Black shouldn't have an opinion because other projects don't have an opinion."

This is an appeal to authority and as such doesn't give us anything actionable to discuss.

I also don't buy the argument that this makes it "unusable for a big part of Python programmers". Why? The code is going to still work, programmers may even continue writing their code with single quotes (and let Black convert it as needed).

Note that Black is using a variant of wrapping lines with brackets that isn't even covered as an option in PEP 8. Does this make Black unusable?

[bofm]

What if a project has an opinion but a different one? Is Black’s intention to change opinions or to be a helpful tool?

[gaggle]

That is a false equivalence @bofm, projects can obviously be opinionated and be helpful. But it may be black isn't for you, no big harm in that right?

For what its worth I don't agree with all black does, but honestly, formatting is such a small pain that I'm 100% ready to outsource the entire concept and accept whatever the community comes up with. It beats hours of bikeshedding. StandardJS has a lot of the same forces acting on it in the Javascript world and they've also had to stick to their guns against many who disagree. I use both, and honestly, it's like an hour and its formatting becomes second nature. My pairing-partner and I spent last week with black (I've just activated it as part of CI), and it's fine. Everything is fine. The maintainers of this project listen to reason but not opinions when deciding a direction, what better principles can we really ask for?

As a matter of practicality, if you do want to use black, have you considered not running it against the entire codebase but limit it to specific folders? With a tiered rollout, you can slowly subsume folders instead of having to orchestrate a big all-or-nothing effort.

[kalekseev]

Option for quotes looks like a simple thing to add to black, if a lot of people argue about that why don't? Why we can have width size option but can't have quote option? Even if you look at the pr it was originally with single quotes by default with argument - it's simpler to type and then switched to double quotes because ' char can be added and quotes will be swapped to " (though now if " char added to the string the opposite will happen). Tab width, line width and quotes where the first options that were added to prettier https://prettier.io/docs/en/options.html (though authors claim that it's opinionated code formatter with minimal set of options as black do).

@bofm overall even if black won't accept option and it crucial for your project you can fork black and apply code from #75 when it was using single quote, it shouldn't be hard to maintain at least at this point.

[ambv]

Black is both a formatter and a code style. One of the core tenets of this project is that all blackened code looks the same. This is why I will never add configurable soft tab width, or identation with hard tabs.

Having options is a burden to the user and a slippery slope to introduce more and more. Case in point: you're already using --line-length as an argument to add something else. The more options, the bigger the need for a configuration file.

We chose to standardize on double quotes because:

• standardizing on one makes sense; and
• standardizing on double quotes makes more sense than single quotes.

I mostly wanted the former and didn't care much which quote is going to be the one we choose. Over the course of designing this with @carljm and @zsol, they convinced me that double quotes are a better option. So this is what Black does now. Shouldn't it be reassuring to users to know that what Black does is informed by rational arguments?

I didn't hear any arguments here that would tell me why single quotes are preferable. "This is what we used to do" doesn't work, Black is bound to be disruptive when adopted. "It's easier to type" is something that I myself said and this was debunked (it's not easier on all keyboard layouts, and more importantly you can keep typing whatever you want and Black will convert it for you).

I'll keep this open because maybe somebody will appear and communicate clearly why an option for this is required. Unless it's strictly necessary, Black won't introduce it.

PS. While forking is always an option in a MIT-licensed project, I felt like suggesting this on my issue tracker was hostile. I would appreciate you not doing that again.

[kalekseev]

PS. While forking is always an option in a MIT-licensed project, I felt like suggesting this on my issue tracker was hostile. I would appreciate you not doing that again.

Sorry, your project is great, I appreciate your work and didn't want to harm anyone with my comments.

[ambv]

Will close this for now. If there's any new evidence of single quotes being preferable over double quotes, we can reopen this and resume discussion.

[lordmauve]

I use single-quoted strings to indicate internal identifiers (eg. dict keys) and double-quoted strings to indicate human-readable text (exception messages and IO).

Roughly if the string matches ^\w+$ I would not enforce double quotes.

[audiolion]

I think this is a really cool project, I hate double quotes though, and more than just typing double quotes, I don't like reading double quotes, quotes are just noise, and I actually really like javascript where you don't have to use quotes at all for dict keys e.g.

const dict = {
    fruits: ['apple', 'orange'],
    veggies: ['carrot', 'turnip'],
}

so single quote is the closest I can get in python to minimizing that noise. When your editor does syntax highlighting, you can easily see what is a string and what isn't.

I read the entire discussion and know you are highly unlikely to change your mind on this, but I want to still voice my opinion.