Closed ncoghlan closed 5 years ago
After creating this, I filed https://github.com/reynoldsnlp/pip_inside/issues/6 based on the further discussion in https://github.com/pypa/pip/issues/5069#issuecomment-450833042
So this PR shouldn't be merged as is - we should decide what we actually want in #6 first.
This has been updated to match my comments on #6 as of https://github.com/reynoldsnlp/pip_inside/issues/6#issuecomment-450856891
Does pypa
have a standard for using double- or single-quotes? I'm happy to use either, but we should do it consistently with whatever pypa
does. (I noticed that I was inconsistent from the get-go, so mea culpa...)
Also, what is the max line length for pypa
? I've been sticking to 79, but I'm happy with whatever pypa
does.
flake8
gives the following:
68 col 40| E261 at least two spaces before inline comment
70 col 27| E999 SyntaxError: invalid syntax
71 col 17| E116 unexpected indentation (comment)
72 col 17| E113 unexpected indentation
72 col 30| E225 missing whitespace around operator
88 col 61| W291 trailing whitespace
Looking at https://github.com/pypa/pip/blob/master/tox.ini, I think pip
just run with the flake8
defaults.
It looks like pip
itself is already inconsistent when it comes to the choice of quote character: https://github.com/pypa/pip/blob/master/src/pip/_internal/commands/configuration.py
@pfmoore, @pradyunsg: Is pip
moving towards using double quotes consistently for strings?
@ncoghlan No we're not. We don't have a mandated standard for quotes to use - it's basically "readability". My personal approach is to use double quotes for "general text" and single quotes for single-character strings and "keywords", but it's not a hard and fast rule.
(Personal rant: I see no sense in a style rule that explicitly disallows use of a language feature such as single quoted strings in all situations, It's my single biggest complaint about the black formatter, for instance.)
I agree with all that @pfmoore said.
Does
pypa
have a standard for using double- or single-quotes? I
AFAICT, each individual project chose what fits them best. pip currently doesn't have any such enforcement.
Refactor and amend the boolean option handling so that:
None
keeps the option from being added to the CLI argument list--
prefix (or-
for single-letter options)--no-
prefixpip
will error out on some combinations that this permits, but the place to resolve that is to make thepip
CLI more consistent (and perhaps eventually add special case handling for some keyword options).