Merge branch 'main' into issue_3860

.github/workflows/release_tests.yml

@@ -0,0 +1,56 @@
+name: Release tool CI
+
+on:
+  push:
+    paths:
+      - .github/workflows/release_tests.yml
+      - release.py
+      - release_tests.py
+  pull_request:
+    paths:
+      - .github/workflows/release_tests.yml
+      - release.py
+      - release_tests.py
+
+jobs:
+  build:
+    # We want to run on external PRs, but not on our own internal PRs as they'll be run
+    # by the push to the branch. Without this if check, checks are duplicated since
+    # internal PRs match both the push and pull_request events.
+    if:
+      github.event_name == 'push' || github.event.pull_request.head.repo.full_name !=
+      github.repository
+
+    name: Running python ${{ matrix.python-version }} on ${{matrix.os}}
+    runs-on: ${{ matrix.os }}
+    strategy:
+      matrix:
+        python-version: ["3.12"]
+        os: [macOS-latest, ubuntu-latest, windows-latest]
+
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          # Give us all history, branches and tags
+          fetch-depth: 0
+      - name: Set up Python ${{ matrix.python-version }}
+        uses: actions/setup-python@v4
+        with:
+          python-version: ${{ matrix.python-version }}
+          allow-prereleases: true
+
+      - name: Print Python Version
+        run: python --version --version && which python
+
+      - name: Print Git Version
+        run: git --version && which git
+
+      - name: Update pip, setuptools + wheels
+        run: |
+          python -m pip install --upgrade pip setuptools wheel
+
+      - name: Run unit tests via coverage + print report
+        run: |
+          python -m pip install coverage
+          coverage run scripts/release_tests.py
+          coverage report --show-missing

CHANGES.md

@@ -14,6 +14,8 @@
 
 - Multiline dictionaries and lists that are the sole argument to a function are now
   indented less (#3964)
+- Multiline list and dict unpacking as the sole argument to a function is now also
+  indented less (#3992)
 
 ### Configuration
 

README.md

@@ -86,7 +86,7 @@ take previous formatting into account (see
 for exceptions).
 
 Our documentation covers the current _Black_ code style, but planned changes to it are
-also documented. They're both worth taking a look:
+also documented. They're both worth taking a look at:
 
 - [The _Black_ Code Style: Current style](https://black.readthedocs.io/en/stable/the_black_code_style/current_style.html)
 - [The _Black_ Code Style: Future style](https://black.readthedocs.io/en/stable/the_black_code_style/future_style.html)

docs/contributing/release_process.md

@@ -32,21 +32,29 @@ The 10,000 foot view of the release process is that you prepare a release PR and
 publish a [GitHub Release]. This triggers [release automation](#release-workflows) that
 builds all release artifacts and publishes them to the various platforms we publish to.
 
+We now have a `scripts/release.py` script to help with cutting the release PRs.
+
+- `python3 scripts/release.py --help` is your friend.
+  - `release.py` has only been tested in Python 3.12 (so get with the times :D)
+
 To cut a release:
 
 1. Determine the release's version number
    - **_Black_ follows the [CalVer] versioning standard using the `YY.M.N` format**
      - So unless there already has been a release during this month, `N` should be `0`
    - Example: the first release in January, 2022 → `22.1.0`
+   - `release.py` will calculate this and log to stderr for you copy paste pleasure
 1. File a PR editing `CHANGES.md` and the docs to version the latest changes
+   - Run `python3 scripts/release.py [--debug]` to generate most changes
+     - Sub headings in the template, if they have no bullet points need manual removal
+       _PR welcome to improve :D_
+1. If `release.py` fail manually edit; otherwise, yay, skip this step!
    1. Replace the `## Unreleased` header with the version number
    1. Remove any empty sections for the current release
    1. (_optional_) Read through and copy-edit the changelog (eg. by moving entries,
       fixing typos, or rephrasing entries)
    1. Double-check that no changelog entries since the last release were put in the
       wrong section (e.g., run `git diff <last release> CHANGES.md`)
-   1. Add a new empty template for the next release above
-      ([template below](#changelog-template))
    1. Update references to the latest version in
       {doc}`/integrations/source_version_control` and
       {doc}`/usage_and_configuration/the_basics`
@@ -63,6 +71,11 @@ To cut a release:
       description box
 1. Publish the GitHub Release, triggering [release automation](#release-workflows) that
    will handle the rest
+1. Once CI is done add + commit (git push - No review) a new empty template for the next
+   release to CHANGES.md _(Template is able to be copy pasted from release.py should we
+   fail)_
+   1. `python3 scripts/release.py --add-changes-template|-a [--debug]`
+   1. Should that fail, please return to copy + paste
 1. At this point, you're basically done. It's good practice to go and [watch and verify
    that all the release workflows pass][black-actions], although you will receive a
    GitHub notification should something fail.
@@ -81,59 +94,6 @@ release is probably unnecessary.
 In the end, use your best judgement and ask other maintainers for their thoughts.
 ```
 
-### Changelog template
-
-Use the following template for a clean changelog after the release:
-
-```
-## Unreleased
-
-### Highlights
-
-<!-- Include any especially major or disruptive changes here -->
-
-### Stable style
-
-<!-- Changes that affect Black's stable style -->
-
-### Preview style
-
-<!-- Changes that affect Black's preview style -->
-
-### Configuration
-
-<!-- Changes to how Black can be configured -->
-
-### Packaging
-
-<!-- Changes to how Black is packaged, such as dependency requirements -->
-
-### Parser
-
-<!-- Changes to the parser or to version autodetection -->
-
-### Performance
-
-<!-- Changes that improve Black's performance. -->
-
-### Output
-
-<!-- Changes to Black's terminal output and error messages -->
-
-### _Blackd_
-
-<!-- Changes to blackd -->
-
-### Integrations
-
-<!-- For example, Docker, GitHub Actions, pre-commit, editors -->
-
-### Documentation
-
-<!-- Major changes to documentation and policies. Small docs changes
-     don't need a changelog entry. -->
-```
-
 ## Release workflows
 
 All of _Black_'s release automation uses [GitHub Actions]. All workflows are therefore

docs/the_black_code_style/future_style.md

@@ -139,6 +139,26 @@ foo([
 ])
 ```
 
+This also applies to list and dictionary unpacking:
+
+```python
+foo(
+    *[
+        a_long_function_name(a_long_variable_name)
+        for a_long_variable_name in some_generator
+    ]
+)
+```
+
+will become:
+
+```python
+foo(*[
+    a_long_function_name(a_long_variable_name)
+    for a_long_variable_name in some_generator
+])
+```
+
 You can use a magic trailing comma to avoid this compacting behavior; by default,
 _Black_ will not reformat the following code: