Update to 20.8b1 #2
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Ensure root dir is a common parent of all inputs Fixes psf#1493
* Add pip install from GitHub command to README.md * Make it prettier ...
Change --config argument description to "Read configuration from FILE." The "--config FILE Read configuration from FILE path"
As Path.resolve() is buggy on windows (see https://bugs.python.org/issue38671) an absolute path is ensured by prepending the Path.cwd()
* pre-commit: --show-diff-on-failure * pre-commit: --show-diff-on-failure
Stable tag wasn't available and crashed when attempting to set initial pre-commit. Also the python version needs to be installed so it would be better to use the generic "python3" command.
Isort 5 introduced profiles and ensure_newline_before_comments options. Either needs to be added to work correctly with black. Co-authored-by: Richard Si <[email protected]>
Co-authored-by: Hugo van Kemenade <[email protected]>
Partial fix for psf#1581 This assertion produces behavior quadratic in the number of leaves in a line, which is making Black extremely slow on files with very long expressions. On my benchmark file this change makes Black 10x faster.
Co-authored-by: Chris Rose <[email protected]>
Ever since --force-exclude was added, --exclude started to touch files that were given to Black through the CLI too. This is not documented behaviour and neither expected as --exclude and --force-exclude now behave the same! Before this commit, get_sources() when encountering a file that was passed explicitly through the CLI would pass a single Path object list to gen_python_files(). This causes bad behaviour since that function doesn't treat the exclude and force_exclude regexes differently. Which is fine for recursively found files, but *not* for files given through the CLI. Now when get_sources() iterates through srcs and encounters a file, it checks if the force_exclude regex matches, if not, then the file will be added to the computed sources set. A new function had to be created since before you can do regex matching, the path must be normalized. The full process of normalizing the path is somewhat long as there is special error handling. I didn't want to duplicate this logic in get_sources() and gen_python_files() so that's why there is a new helper function.
Make Black failures easier to debug
Allow removing some trailing whitespace
Refer to `pyproject.toml` in HTML section of README with HTML code tags
* put experimental string stuff behind a flag * update tests * don't need an output section if it's the same as the input * Primer: Expect no formatting changes in attrs, hypothesis and poetry with --experimental-string-processing off Co-authored-by: Hugo van Kemenade <[email protected]>
* Upgrade docs to Sphinx 3+ * Fix all the warnings... - Fixed bad docstrings - Fixed bad fenced code blocks in documentation - Blocklisted some sections from being generated from the README - Added missing documentation to index.rst - Fixed an invalid autofunction directive in reference/reference_functions.rst - Pin another documentation dependency * Add documentation build test
- when a trailing comma is specified in any bracket pair, that signals to Black that this bracket pair needs to be always exploded, e.g. presented as "one item per line"; - this causes some changes to previously formatted code that erroneously left trailing commas embedded into single-line expressions; - internally, Black needs to be able to identify trailing commas that it put itself compared to pre-existing trailing commas. We do this by using/abusing lib2to3's `was_checked` attribute. It's True for internally generated trailing commas and False for pre-existing ones (in fact, for all pre-existing leaves and nodes). Fixes psf#1288
…t pair This required some hackery. Long story short, we need to reuse the ability to omit rightmost bracket pairs (which glues them together and splits on something else instead), for use with pre-existing trailing commas. This form of user-controlled formatting is brittle so we have to be careful not to cause a scenario where Black first formats code without trailing commas in one way, and then looks at the same file with pre-existing trailing commas (that it itself put on the previous run) and decides to format the code again. One particular ugly edge case here is handling of optional parentheses. In particular, the long-standing `line_length=1` hack got in the way of pre-existing trailing commas and had to be removed. Instead, a more intelligent but costly solution was put in place: a "second opinion" if the formatting that omits optional parentheses ended up causing lines to be too long. Again, for efficiency purposes, Black reuses Leaf objects from blib2to3 and modifies them in place, which was invalid for having two separate formattings. Line cloning was used to mitigate this. Fixes psf#1619
This addresses a few crashers, namely: * producing non-equivalent code due to mangling escaped newlines, * invalid hugging quote characters in the docstring body to the docstring outer triple quotes (causing a quadruple quote which is a syntax error), * lack of handling for docstrings that start on the same line as the `def`, and * invalid stripping of outer triple quotes when the docstring contained a string prefix. As a bonus, tests now also run when string normalization is disabled.
…1622) Co-authored-by: Łukasz Langa <[email protected]>
Reformatted projects I have acceess to: - aioexabgp - bandersnatch - flake8-bugbear ``` -- primer results 📊 -- 13 / 16 succeeded (81.25%) ✅ 0 / 16 FAILED (0.0%) 💩 - 3 projects disabled by config - 0 projects skipped due to Python version - 0 skipped due to long checkout ``` * Also re-enable pytest ``` -- primer results 📊 -- 14 / 16 succeeded (87.5%) ✅ 0 / 16 FAILED (0.0%) 💩 - 2 projects disabled by config - 0 projects skipped due to Python version - 0 skipped due to long checkout real 2m26.207s user 17m55.404s sys 0m43.061s ```
On a second pass of Black on the same file, inserted trailing commas are now pre-existing. Doesn't make sense to differentiate between the passes then.
dwanderson-intel
pushed a commit
that referenced
this pull request
Oct 5, 2022
This commit fixes parsing of the skip-string-normalization option in vim plugin. Originally, the plugin read the string-normalization option, which does not exist in help (--help) and it's not respected by black on command line. Commit history before merge: * fix string normalization option in vim plugin * fix string normalization option in vim plugin * Finish and fix patch (thanks Matt Wozniski!) FYI: this is totally the work and the comments below of Matt (AKA godlygeek) This fixes two entirely different problems related to how pyproject.toml files are handled by the vim plugin. === Problem #1 === The plugin fails to properly read boolean values from pyproject.toml. For instance, if you create this pyproject.toml: ``` [tool.black] quiet = true ``` the Black CLI is happy with it and runs without any messages, but the :Black command provided by this plugin fails with: ``` Traceback (most recent call last): File "<string>", line 1, in <module> File "<string>", line 102, in Black File "<string>", line 150, in get_configs File "<string>", line 150, in <dictcomp> File "/usr/lib/python3.6/distutils/util.py", line 311, in strtobool val = val.lower() AttributeError: 'bool' object has no attribute 'lower' ``` That's because the value returned by the toml.load() is already a bool, but the vim plugin incorrectly tries to convert it from a str to a bool. The value returned by toml_config.get() was always being passed to flag.cast(), which is a function that either converts a string to an int or a string to a bool, depending on the flag. vim.eval() returns integers and strings all as str, which is why we need the cast, but that's the wrong thing to do for values that came from toml.load(). We should be applying the cast only to the return from vim.eval() (since we know it always gives us a string), rather than casting the value that toml.load() found - which is already the right type. === Problem #2 === The vim plugin fails to take the value for skip_string_normalization from pyproject.toml. That's because it looks for a string_normalization key instead of a skip_string_normalization key, thanks to this line saying the name of the flag is string_normalization: black/autoload/black.vim (line 25 in 05b54b8) ``` Flag(name="string_normalization", cast=strtobool), ``` and this dictcomp looking up each flag's name in the config dict: black/autoload/black.vim (lines 148 to 151 in 05b54b8) ``` return { flag.var_name: flag.cast(toml_config.get(flag.name, vim.eval(flag.vim_rc_name))) for flag in FLAGS } ``` For the second issue, I think I'd do a slightly different patch. I'd keep the change to invert this flag's meaning and change its name that this PR proposes, but I'd also change the handling of the g:black_skip_string_normalization and g:black_string_normalization variables to make it clear that g:black_skip_string_normalization is the expected name, and g:black_string_normalization is only checked when the expected name is unset, for backwards compatibility. My proposed behavior is to check if g:black_skip_string_normalization is defined and to define it if not, using the inverse of g:black_string_normalization if that is set, and otherwise to the default of 0. The Python code in autoload/black.vim runs later, and will use the value of g:black_skip_string_normalization (and ignore g:black_string_normalization; it will only be used to set g:black_skip_string_normalization if it wasn't already set). --- Co-authored-by: Matt Wozniski <[email protected]> * Fix plugin/black.vim (need to up my vim game) Co-authored-by: Matt Wozniski <[email protected]> Co-authored-by: Richard Si <[email protected]> Co-authored-by: Matt Wozniski <[email protected]> Co-authored-by: Matt Wozniski <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes the trailing comma issue.