Keep single-line signatures when body is an Ellipsis (...) in .py files

[etienneschalk]

A minimal code snippet that reproduces the bug.

File name: format_ruff.py

Before ruff:

class MyClass:
    def __add__(self, other: int) -> int: ...

After ruff:

class MyClass:
    def __add__(self, other: int) -> int:
        ...

The command you invoked

ruff format format_ruff.py 

Note: in real-life scenario, one might have installed the Ruff extension on VSCode, opened a file with many stubs like in the minimal code snippet, and see them all formatted, introducing unwanted code change, which can be annoying for version control.

This might also slow down ruff adoption in existing large code bases where the case mentioned above happens a lot.

The current Ruff settings

No overriden settings. I ran a pip install ruff then ran the command above

The current Ruff version

ruff --version
ruff 0.2.2

What I would like

A way to opt-out of de-inlining the Ellipsis (...) in stubs. I have searched in documentation without finding such an option. I browsed the following issues (in Links section).

An option could be:

[tool.ruff.format]
keep-single-line-ellipsis = true

Links

Related Issues:

• Formatter: Ellipses in stub files get formatted on a single line #5822 -> It seems the solution only applied to .pyi files, not .py ; I would like the option to be activable for all types of files.
• Allow reduced number of blank lines for dummy implementations psf/black#1797 (referred to in the issue above)

Related PRs:

• Format function and class definitions into a single line if its body is an ellipsis #6592 (exposes the same situation described in this issue! it seems to only apply to .pyi files, but maybe it could be generalized to .py?)
• Use one line between top-level items if formatting a stub file #6501

Thanks!

[MichaReiser]

Thanks for the excellent writeup! We've implemented your desired behavior but it's currently only applied when you format your code with --preview mode enabled as you can see here https://play.ruff.rs/6cc50dba-b5ae-4dea-9f58-14b179932e65.

We hope to promote the new formatting to stable in this month, but you can already start using it if you enable ruff.format.preview = true or call ruff format --preview

Let me know if that works for you

[etienneschalk]

Hello, thanks for you answer!

I ran a pre-commit run --all after enabling the preview flag in pyproject.toml:

[tool.ruff.format]
preview = true

It puts back the Ellipses back on their single line 👍

However, it also brings new changes, mainly compressing multiple braces in a javascript formatting style.

Excerpt from the xarray repo:

-        self.ds = Dataset(
-            {
-                "a": (("x", "y"), np.ones((300, 400))),
-                "b": (("x", "y"), np.ones((300, 400))),
-            }
-        )
+        self.ds = Dataset({
+            "a": (("x", "y"), np.ones((300, 400))),
+            "b": (("x", "y"), np.ones((300, 400))),
+        })

Even though I personally like this new formatting (it looks like javascript formatting, is more concise, and saves a level of indentation), I would still like to get more granularity inside of the preview flag, to choose which features to opt-in (orthogonal configuration), reducing code diff at the same time in a migration context.

According to the documentation of Preview we can select rules for the linter with explicit-preview-rules = true, however I cannot find an equivalent for the formatter. Is there a "formatting rule" concept, equivalent to the "linting rules", that would enable me to opt-in only the Ellipsis formatting rule?

Thanks!

[MichaReiser]

That makes sense. There's no such granular opt-in to preview formatting. It's all or nothing, similar to the formatter itself which only provides very few configuration nobs.

For preview, this is especially important because it ensures that users give feedback to all preview styles and don't just disable the styles they don't like. It prevents situations where all users disabled a controversial style change but we decide releasing it because we never received any negative feedback on the style.

[etienneschalk]

Okay, I fully understand the point of having a single preview style!

Thanks a lot for the help on that topic!

[MichaReiser]

I'll close this issue. You can follow #8678 to get notified when we promote the new preview styles (The style you're calling out won't be promoted)