Consider enforcing some kind of quote consistency in Python code

[maxkossek]

@maxkossek, Remember that the Tax-Calculator Python coding style is to use single quotes.

Originally posted by @martinholmer in #2943 (comment)

Add the pylint-quotes package to environment.yml and then include it in the cstest in Makefile to enforce single quote Pythons style. This would also require a new .pylintrc file that specifies the types of quotes we want for these types of Python strings: string-quote, triple-quote, and docstring-quote.

@martinholmer noted that to pass the initial test would require a significant number of changes to enforce the style in existing files:

The cost of enforcing this would be non-trivial as shown by these results:

(taxcalc-dev) Tax-Calculator> grep -r --include="*py" \" . | grep -v \"\"\" | wc -l 
   1215

There are a few lines that use double quotes in a situation in which both type of quotes are necessary.

Originally posted by @martinholmer in #2943 (comment)

The enforcement costs may not be worth it if this rule would require manual logic and exceptions for many files.

[martinholmer]

Another option (besides using the pylint-quotes plugin) would be to use the built-in pylint quote consistency checking capability (see the pylint docs for details).

The pylint-quotes plugin enforces a consistent quote style across all Python modules, which would require much work in Tax-Calculator because we have never enforced a consistent use of quotes.

The built-in pylint capability enforces a less stringent form of quote consistency: it warns only if there is inconsistent quoting (that is, some double-quoted strings and some single-quoted strings) in the same .py module. This means that old code that uses double-quoted strings consistently will not generate a warning.

It strikes me that this is the main benefit of consistency: that the code in (for example) policy.py uses a consistent quoting style, and is therefore, more readable.

[martinholmer]

Seems like the first step is to implement the built-in pylint quote consistency checking, which will improve the readability of each Python module at minimum cost. Then after gaining experience with that enhanced "make cstest", we can evaluate the benefits and costs of enforcing quote consistency across all the Python modules using the pylint-quotes plugin.

@jdebacker, @maxkossek, Does this make sense as a course of action?

[jdebacker]

I'm a fan of using black. I'm using it in Cost-of-Capital-Calculator, OG-Core, OG-USA, InverseOptimalTax, and others.

What I like: simple, easy to write tests against, can avoid ruining git blame

I think PolicyEngine also uses black.

[martinholmer]

@jdebacker said in issue #2950:

I'm a fan of using black. I'm using it in Cost-of-Capital-Calculator, OG-Core, OG-USA, InverseOptimalTax, and others.

What I like: simple, easy to write tests against, can avoid ruining git blame

I think PolicyEngine also uses black.

Yes, I know black has fans, but it enforces an extreme formatting style including the manditory use of double quotes. And I think the way it breaks long lines make the code close to unreadable by humans.
So, after using black for several years in the PolicyEngine-US project, I aim most definitely not a fan.
We are trying to make an incremental change here.