Every one of the projects in this repository is available at the canonical
URL git://git.madduck.net/madduck/pub/<projectpath> — see
each project's metadata for the exact URL.
All patches and comments are welcome. Please squash your changes to logical
commits before using git-format-patch and git-send-email to
patches@git.madduck.net.
If you'd read over the Git project's submission guidelines and adhered to them,
I'd be especially grateful.
Richard Si [Mon, 26 Apr 2021 20:26:43 +0000 (16:26 -0400)]
Stop stripping parens in even more illegal spots (#2148)
We're only fixing them so fuzzers don't yell at us when we break "valid"
code. I mean "valid" because some of the examples aren't even accepted by
Python.
Richard Si [Mon, 26 Apr 2021 15:28:42 +0000 (11:28 -0400)]
Don't strip parens in assert / return with assign expr (#2143)
Black would previously strip the parenthesis away from statements like this these ones:
assert (spam := 12 + 1)
return (cheese := 1 - 12)
Which happens to be invalid code. Now before making the parenthesis invisible, Black
checks if the assignment expression's parent is an assert stamtment, aborting if True.
Raise, yield, and await are already handled fine.
I added a bunch of test cases from the PEP defining asssignment expressions (PEP 572).
Cooper Lees [Sun, 25 Apr 2021 21:51:13 +0000 (14:51 -0700)]
Docker CI: Add missed Checkout step (#2128)
- Reading my error others hit it by forgetting this Checkoutstep too so trying the fix
- e.g. https://github.com/docker/build-push-action/issues/179
- Makes sense it's needed
Work around stability errors due to optional trailing commas (#2126)
Optional trailing commas put by Black become magic trailing commas on another
pass of the tool. Since they are influencing formatting around optional
parentheses, on rare occasions the tool changes its mind in terms of putting
parentheses or not.
Ideally this would never be the case but sadly the decision to put optional
parentheses or not (which looks at pre-existing "magic" trailing commas) is
happening around the same time as the decision to put an optional trailing
comma. Untangling the two proved to be impractically difficult.
This shameful workaround uses the fact that the formatting instability
introduced by magic trailing commas is deterministic: if the optional trailing
comma becoming a pre-existing "magic" trailing comma changes formatting, the
second pass becomes stable since there is no variable factor anymore on pass 3,
4, and so on.
For most files, this will introduce no performance penalty since `--safe` is
already re-formatting everything twice to ensure formatting stability. We're
using this result and if all's good, the behavior is equivalent. If there is
a difference, we treat the second result as the binding one, and check its
sanity again.
Cooper Lees [Thu, 8 Apr 2021 04:13:11 +0000 (21:13 -0700)]
Add `black` Dockerfile (#1916)
* Add `black` Dockerfile
- Build a `black` container based on python3-slim
- Test: `docker build --network-host --tag black .`
```console
cooper-mbp1:black cooper$ docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
black latest 0c7636402ac2 4 seconds ago 332MB
```
Addresses part of #1914
* Build with colorama + d extra installs - Adds ~9mb
* Combine all build commands in 1 run
- Combine the commands all into 1 RUN to down the size
- Get to 65.98 MB image size now: https://hub.docker.com/repository/docker/cooperlees/black/tags?page=1&ordering=last_updated
* Add rm -r of /var/lib/apt/lists/* + save 10mb down to 55mb
Richard Si [Thu, 1 Apr 2021 21:24:18 +0000 (17:24 -0400)]
Push contributors to use Next PR Number (#2080)
This is a tool of my own making. Right now our requirement to have the
PR number in the changelog entry is pretty painful / annoying since
the contributor either has to guess or add the # retroactively after
the PR creation. This tool should make it way less painful by making
it simple to get your PR number beforehand.
At the user level, a TOML config can be specified in the following locations:
* Windows: ~\.black
* Unix-like: $XDG_CONFIG_HOME/black (~/.config/black fallback)
Instead of changing env vars for the entire black-primer process, they
are now changed only for the black subprocess, using a tmpdir.
Richard Si [Wed, 24 Mar 2021 23:38:07 +0000 (19:38 -0400)]
Add entry for `--extend-exclude` in the right place (#2061)
The PR author added the changelog entry for their `extend-exclude` addition
in `docs/change_log.md` which is understandable but incorrect as it will be
overwritten since it's autogenerated from the readme.
Cooper Lees [Sun, 21 Mar 2021 20:05:24 +0000 (13:05 -0700)]
Add a GitHub CHANGELOG/News Check (#2057)
- Run grep to see commit has a line mentioning it to CHANGES.md
- Also add a label to disable this being required for PRs that don't need a change entry
Jairo Llopis [Thu, 18 Mar 2021 15:14:15 +0000 (15:14 +0000)]
Recommend B950 + 88 char limit instead of 80 (#2050)
[The section about line length][1] was contradictory.
On one side, it said:
> Black will try to respect that [line length limit]. However, sometimes it won't be able to without breaking other rules. In those rare cases, auto-formatted code will exceed your allotted limit.
So black doesn't guarantee that your code is formatted at 88 chars, even when configured with `--line-length=88` (default). Black uses this limit as a "hint" more than a "rule".
OTOH, it also said:
> If you're using Flake8, you can bump max-line-length to 88 and forget about it. Alternatively, use Bugbear's B950 warning instead of E501 and keep the max line length at 80 which you are probably already using.
But that's not true. You can't "forget about it" because Black sometimes won't respect the limit. Both E501 at 88 and B950 at 80 behave the same: linter error at 89+ length. So, if Black happens to decide that a line of code is better at 90 characters that some other fancy style, you land on a unlucky situation where both tools will fight.
So, AFAICS, the best way to align flake8 and black is to:
1. Use flake8-bugbear
2. Enable B950
3. Disable E501
4. Set `max-line-length = 88`
This way, we also tell flake8 that 88 limit is a "hint" and not a "rule". The real rule will be 88 + 10%. If black decides that a line fits better in 97 characters than in 88 + some formatting, _that_ probably means your code has a real problem.
To avoid further confusion, I change the official recommendation here.
Indicate that a final newline was added in --diff (#1897) (#1897)
Fixes: #1662
Work-around for https://bugs.python.org/issue2142
The test has to slightly mess with its input data, because the utility
functions default to ensuring the test data has a final newline, which
defeats the point of the test.
Signed-off-by: Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>
James Addison [Sat, 20 Feb 2021 16:44:48 +0000 (16:44 +0000)]
fuzzer: add special-case for multi-line EOF TokenError (#1991)
* Add special-case for multi-line EOF TokenError under Python3.7
* Update conditional check to correspond to original issue description (and include issue hyperlink)
* Add warning and hint regarding replaying the fuzzer code generation
* Include code review suggestion (with modifications for this to follow)
Co-authored-by: Zac Hatfield-Dodds <zac.hatfield.dodds@gmail.com>
* Remove Python version check, since this issue does exist across more recent Python versions than 3.7
* Update explanatory comment
* Add clarification for potentially-ambiguous blib2to3 import
* Update explanatory comment
* Bring comment into consistent format with previous comment
* Revert "Add clarification for potentially-ambiguous blib2to3 import"
rht [Sun, 14 Feb 2021 15:32:29 +0000 (10:32 -0500)]
readme: Include Zulip in used-by section (#1987)
Zulip has recently formatted their code in Black and also set Black as a linter: https://github.com/zulip/zulip/pull/15662.
See also https://chat.zulip.org/#narrow/stream/2-general/topic/black.
Richard Si [Sun, 14 Feb 2021 15:23:47 +0000 (10:23 -0500)]
Fix duplication of checks on internal PRs (#1986)
Internal PRs (that come from branches of psf/black) match both the push
and pull_request events. This leads to a duplication of test, lint, etc.
checks on such PRs. Not only is it a waste of resources, it makes the
Status Checks UI more frustrating to go through.
Patch taken from:
https://github.community/t/duplicate-checks-on-push-and-pull-request-simultaneous-event/18012
James Addison [Thu, 11 Feb 2021 20:11:42 +0000 (20:11 +0000)]
Stability fixup: interaction between newlines and comments (#1975)
* Add test case to illustrate the issue
* Accept carriage returns as valid separators while enumerating comments
Without this acceptance, escaped multi-line statments that use carriage returns will not be counted into the 'ignored_lines' variable since the emitted line values will end with a CR and not an escape character. That leads to comments associated with the line being incorrectly labeled with the STANDALONE_COMMENT type, affecting comment placement and line space management.
Richard Si [Fri, 5 Feb 2021 04:10:45 +0000 (23:10 -0500)]
Update prettier in pre-commit config (#1966)
With older versions of prettier, when the hook failed a bunch of
"[error] No parser could be inferred for file: {PATH}" error lines
showed up because of lack of support of a flag that pre-commit
passes for us by default. It made figuring out why the prettier hook
failed annoying.
Oliver Newman [Wed, 27 Jan 2021 17:36:21 +0000 (12:36 -0500)]
Update example exclude to match only files in root (#1861)
* Update example exclude to match only files in root
The `exclude` section of the example `pyproject.toml` file didn't work
as expected. It claimed to exclude matched files only in the project
root, but it actually excluded matched files at any directory level
within the project. We can address this by prepending `^/` to the regex
to ensure that it only matches files in the project root.
See https://github.com/psf/black/issues/1473#issuecomment-740008873 for
explanation.
Jon Dufresne [Thu, 31 Dec 2020 17:09:07 +0000 (09:09 -0800)]
Add pyi file support to .pre-commit-hooks.yaml (#1875)
Since pre-commit 2.9.0 (2020-11-21), the types_or key can be used to
match multiple disparate file types. For more upstream details, see:
https://github.com/pre-commit/pre-commit/issues/607
Add the minimum_pre_commit_version to require pre-commit 2.9.0+.
Richard Si [Mon, 28 Dec 2020 02:38:11 +0000 (21:38 -0500)]
Bump mypy to 0.780 in pre-commit config (#1887)
To avoid hitting a mypy bug causes pre-commit to always fail on CPython
3.9. Even though it's still an outdated version, the bug effectively
blocks development on CPython 3.9 so that's why this commit exists
instead of waiting for cooperlees to finish his bump to 0.790 PR.
Also this fixes primer to ensure it always raises CalledProcessError
with an int error code. I stole the patch from cooperlees's mypy bump
PR.
It's funny how mypy 0.790 is already asked for in our
Pipfile.lock file, but oh well mypy is probably more commonly run
through pre-commit than standalone I guess.
Oh and if you're curious why the bug doesn't up on CPython 3.8 or lower:
there was some subscription AST changes in CPython 3.9.
projects / etc / vim.git / log