Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Group function definition parameters with return type annotations #6410

Merged
merged 2 commits into from
Aug 9, 2023

Conversation

charliermarsh
Copy link
Member

@charliermarsh charliermarsh commented Aug 8, 2023

Summary

This PR removes the group around function definition parameters, instead grouping the parameters with the type parameters and return type annotation.

This increases Zulip's similarity score from 0.99385 to 0.99699, so it's a meaningful improvement. However, there's at least one stability error that I'm working on, and I'm really just looking for high-level feedback at this point, because I'm not happy with the solution.

Closes #6352.

Test Plan

Before:

  • zulip: 0.99396
  • django: 0.99784
  • warehouse: 0.99578
  • build: 0.75436
  • transformers: 0.99407
  • cpython: 0.75987
  • typeshed: 0.74432

After:

  • zulip: 0.99702
  • django: 0.99784
  • warehouse: 0.99585
  • build: 0.75623
  • transformers: 0.99470
  • cpython: 0.75988
  • typeshed: 0.74853

@charliermarsh charliermarsh added the formatter Related to the formatter label Aug 8, 2023
@charliermarsh charliermarsh marked this pull request as draft August 8, 2023 01:40
@charliermarsh charliermarsh marked this pull request as ready for review August 8, 2023 01:40
@charliermarsh
Copy link
Member Author

charliermarsh commented Aug 8, 2023

As I said in the summary, I'd like feedback on with_ungroup, or whether I should be doing this completely differently. I'm not yet looking for approval (but I also don't want to mark it as draft, since I do want eyes on it).

@charliermarsh charliermarsh changed the base branch from charlie/empty-parenthesized to charlie/dangling August 8, 2023 01:55
@charliermarsh
Copy link
Member Author

(I think this also breaks the behavior whereby we insert a trailing comma if the parameters group breaks, but I believe I can fix that.)

@github-actions
Copy link
Contributor

github-actions bot commented Aug 8, 2023

PR Check Results

Benchmark

Linux

group                                      main                                   pr
-----                                      ----                                   --
formatter/large/dataset.py                 1.02      8.4±0.05ms     4.9 MB/sec    1.00      8.2±0.03ms     4.9 MB/sec
formatter/numpy/ctypeslib.py               1.03  1637.1±13.26µs    10.2 MB/sec    1.00  1592.1±10.64µs    10.5 MB/sec
formatter/numpy/globals.py                 1.03    176.0±0.55µs    16.8 MB/sec    1.00    170.4±1.99µs    17.3 MB/sec
formatter/pydantic/types.py                1.03      3.6±0.05ms     7.1 MB/sec    1.00      3.5±0.02ms     7.3 MB/sec
linter/all-rules/large/dataset.py          1.00     10.5±0.02ms     3.9 MB/sec    1.01     10.6±0.03ms     3.8 MB/sec
linter/all-rules/numpy/ctypeslib.py        1.00      2.9±0.01ms     5.8 MB/sec    1.00      2.9±0.01ms     5.8 MB/sec
linter/all-rules/numpy/globals.py          1.01    319.0±2.29µs     9.3 MB/sec    1.00    316.8±1.66µs     9.3 MB/sec
linter/all-rules/pydantic/types.py         1.12      5.5±0.09ms     4.7 MB/sec    1.00      4.9±0.03ms     5.2 MB/sec
linter/default-rules/large/dataset.py      1.01      5.5±0.02ms     7.4 MB/sec    1.00      5.5±0.02ms     7.5 MB/sec
linter/default-rules/numpy/ctypeslib.py    1.02   1153.3±5.46µs    14.4 MB/sec    1.00   1127.2±5.47µs    14.8 MB/sec
linter/default-rules/numpy/globals.py      1.02    117.3±2.69µs    25.2 MB/sec    1.00    114.6±0.30µs    25.7 MB/sec
linter/default-rules/pydantic/types.py     1.02      2.5±0.01ms    10.3 MB/sec    1.00      2.4±0.02ms    10.5 MB/sec

Windows

group                                      main                                   pr
-----                                      ----                                   --
formatter/large/dataset.py                 1.03     10.0±0.12ms     4.1 MB/sec    1.00      9.8±0.03ms     4.2 MB/sec
formatter/numpy/ctypeslib.py               1.06  1963.6±38.15µs     8.5 MB/sec    1.00  1860.4±15.01µs     9.0 MB/sec
formatter/numpy/globals.py                 1.02    197.5±1.86µs    14.9 MB/sec    1.00    194.0±3.57µs    15.2 MB/sec
formatter/pydantic/types.py                1.04      4.3±0.08ms     5.9 MB/sec    1.00      4.2±0.04ms     6.1 MB/sec
linter/all-rules/large/dataset.py          1.02     13.2±0.22ms     3.1 MB/sec    1.00     12.9±0.18ms     3.1 MB/sec
linter/all-rules/numpy/ctypeslib.py        1.01      3.6±0.03ms     4.6 MB/sec    1.00      3.6±0.03ms     4.6 MB/sec
linter/all-rules/numpy/globals.py          1.02    374.9±7.97µs     7.9 MB/sec    1.00    367.6±5.51µs     8.0 MB/sec
linter/all-rules/pydantic/types.py         1.13      6.9±0.05ms     3.7 MB/sec    1.00      6.1±0.05ms     4.2 MB/sec
linter/default-rules/large/dataset.py      1.01      7.0±0.18ms     5.8 MB/sec    1.00      6.9±0.12ms     5.9 MB/sec
linter/default-rules/numpy/ctypeslib.py    1.02  1404.7±26.09µs    11.9 MB/sec    1.00  1371.8±18.16µs    12.1 MB/sec
linter/default-rules/numpy/globals.py      1.03    143.6±1.47µs    20.5 MB/sec    1.00    138.8±1.01µs    21.3 MB/sec
linter/default-rules/pydantic/types.py     1.02      3.1±0.01ms     8.3 MB/sec    1.00      3.0±0.02ms     8.5 MB/sec

@charliermarsh charliermarsh force-pushed the charlie/dangling branch 6 times, most recently from 03eb93f to 862e7ad Compare August 8, 2023 03:49
Copy link
Member

@konstin konstin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at the black test cases, i think the following is another one of those where black doesn't add parentheses if it doesn't help with fitting:

black:

def foo(
    a: int,
    b: int,
    c: int,
) -> intsdfsafafafdfdsasdfsfsdfasdfafdsafdfdsfasdskdsdsfdsafdsafsdfdasfffsfdsfdsafafhdskfhdsfjdslkfdlfsdkjhsdfjkdshfkljds:
    return 2

ours:

def foo(
    a: int,
    b: int,
    c: int,
) -> (
    intsdfsafafafdfdsasdfsfsdfasdfafdsafdfdsfasdskdsdsfdsafdsafsdfdasfffsfdsfdsafafhdskfhdsfjdslkfdlfsdkjhsdfjkdshfkljds
):
    return 2

Otherwise black_compatibility@simple_cases__return_annotation_brackets.py.snap looks good

crates/ruff_python_formatter/src/expression/parentheses.rs Outdated Show resolved Hide resolved
@charliermarsh charliermarsh force-pushed the charlie/dangling branch 4 times, most recently from 2161c23 to 8cc0a1d Compare August 8, 2023 19:22
@charliermarsh
Copy link
Member Author

Okay, this got way simpler thanks for the feedback.

Base automatically changed from charlie/dangling to main August 8, 2023 20:48
charliermarsh added a commit that referenced this pull request Aug 8, 2023
…6413)

## Summary

Given:

```python
def double(a: int) -> ( # Hello
    int
):
    return 2*a
```

We currently treat `# Hello` as a trailing comment on the parameters
(`(a: int)`). This PR adds a placement method to instead treat it as a
dangling comment on the function definition itself, so that it gets
formatted at the end of the definition, like:

```python
def double(a: int) -> int:  # Hello
    return 2*a
```

The formatting in this case is unchanged, but it's incorrect IMO for
that to be a trailing comment on the parameters, and that placement
leads to an instability after changing the grouping in #6410.

Fixing this led to a _different_ instability related to tuple return
type annotations, like:

```python
def zrevrangebylex(self, name: _Key, max: _Value, min: _Value, start: int | None = None, num: int | None = None) -> (  # type: ignore[override]
):
    ...
```

(This is a real example.)

To fix, I had to special-case tuples in that spot, though I'm not
certain that's correct.
@MichaReiser
Copy link
Member

Current dependencies on/for this PR:

This comment was auto-generated by Graphite.

Co-authored-by: Micha Reiser <micha@reiser.io>
@charliermarsh charliermarsh enabled auto-merge (squash) August 9, 2023 12:07
@charliermarsh charliermarsh merged commit 3bf1c66 into main Aug 9, 2023
16 checks passed
@charliermarsh charliermarsh deleted the charlie/function-signature-ii branch August 9, 2023 12:14
durumu pushed a commit to durumu/ruff that referenced this pull request Aug 12, 2023
…stral-sh#6413)

## Summary

Given:

```python
def double(a: int) -> ( # Hello
    int
):
    return 2*a
```

We currently treat `# Hello` as a trailing comment on the parameters
(`(a: int)`). This PR adds a placement method to instead treat it as a
dangling comment on the function definition itself, so that it gets
formatted at the end of the definition, like:

```python
def double(a: int) -> int:  # Hello
    return 2*a
```

The formatting in this case is unchanged, but it's incorrect IMO for
that to be a trailing comment on the parameters, and that placement
leads to an instability after changing the grouping in astral-sh#6410.

Fixing this led to a _different_ instability related to tuple return
type annotations, like:

```python
def zrevrangebylex(self, name: _Key, max: _Value, min: _Value, start: int | None = None, num: int | None = None) -> (  # type: ignore[override]
):
    ...
```

(This is a real example.)

To fix, I had to special-case tuples in that spot, though I'm not
certain that's correct.
durumu pushed a commit to durumu/ruff that referenced this pull request Aug 12, 2023
…tral-sh#6410)

## Summary

This PR removes the group around function definition parameters, instead
grouping the parameters with the type parameters and return type
annotation.

This increases Zulip's similarity score from 0.99385 to 0.99699, so it's
a meaningful improvement. However, there's at least one stability error
that I'm working on, and I'm really just looking for high-level feedback
at this point, because I'm not happy with the solution.

Closes astral-sh#6352.

## Test Plan

Before:

- `zulip`: 0.99396
- `django`: 0.99784
- `warehouse`: 0.99578
- `build`: 0.75436
- `transformers`: 0.99407
- `cpython`: 0.75987
- `typeshed`: 0.74432

After:

- `zulip`: 0.99702
- `django`: 0.99784
- `warehouse`: 0.99585
- `build`: 0.75623
- `transformers`: 0.99470
- `cpython`: 0.75988
- `typeshed`: 0.74853
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
formatter Related to the formatter
Projects
None yet
Development

Successfully merging this pull request may close these issues.

formatter prefers to break annotation over arguments list
3 participants