What are your plans for the Black 2025 style guide?

[MichaReiser]

Hi

January isn't too far off anymore ;), and I was wondering if you already have plans for what preview features you want to stabilize as part of the Black 2025 style guide.

I'm working on Ruff's formatter, and my goal is to align Ruff's preview-style promotions with Black's to have a unified 2025 Python style guide (at least style guides that are very close).

New Black preview styles that you implemented during 2024 that I'm aware of (that aren't bug fixes):

• remove_redundant_guard_parens Parenthesize match..case if guards astral-sh/ruff#13513
• parens_for_long_if_clauses_in_case_block (related to remove_redundant_guard_parens): See #10969 Parenthesize match..case if guards astral-sh/ruff#13513
• no_normalize_fmt_skip_whitespace: Don't normalize leading whitespace before fmt: skip comments.

Ruff already supports the two match..case preview styles. We might get around to implementing no_normalize_fmt_skip_whitespace as well, but I don't consider it as crucial as it is a minor style change.

Black preview styles that weren't stabilized last year:

• wrap_long_dict_values_in_parens: We decided not to support this style for now because it introduces new parentheses which is a paradigma change.
• multiline_string_handling. We plan on shipping a simplified version of this, see below
• hug_parens_with_braces_and_square_brackets: I would love to see this stabilize but I'm aware it's a big change and there are some open questions.
• hex_codes_in_unicode_sequences: We stabilized this change last year because we assumed Black did, too. We haven't received much push back but some users assumed that changing the casing changes the runtime values (Ruff formatter - unicode string inside of Enum object always lowercasing characters astral-sh/ruff#13859) and some users wished that Ruff defaults to lowercase (Feature request: Option to use lowercase hex literals astral-sh/ruff#10432)

The following are Ruff style changes that we consider to ship as part of the 2025 style guide:

• join_implicit_concatenated_strings and Join implicit concatenated strings when they fit on a line astral-sh/ruff#13663: This is a simplified version of multiline_string_handling that only joins, but never automatically splits strings. The overall changes look very promising to me. However, I had to make some changes to the assert formatting that would be a medium large deviation from Black
• fstring-formatting and Alternate quotes for strings inside f-strings in preview  astral-sh/ruff#13860: Format f-string expressions. This includes normalizing the quotes and formatting the nested expressions (where permitted)

I would appreciate any comments regarding your plans for the Black 2025 style guide as well as any concerns you may have about the new Ruff preview styles.

[JelleZijlstra]

Thanks, you're right that it's almost time to start thinking about this. I don't have a lot of time right now, but my general expectation is that we'll stabilize all the changes currently in preview but not the ones in unstable, unless someone contributes a fix for the bugs that made those changes go into the unstable style.

I agree with the direction of making smaller changes to strings, partly split out from our string_processing feature. we should ideally also format f-string internals, but we'll need a contributor to help us do it safely.

[Montg0mery]

I'm strongly in favour of lowercase hex literals as an option, in both Black and ruff ( #1692 / astral-sh/ruff#10432 ). If both projects implemented it as an option then you wouldn't have to change the default (which would cause code that was previously compliant to become non-compliant). It would also maintain compatibility between the two tools, as long as someone used the same configuration option for both in the same way that they already currently have to with the options for line length, magic quotes etc.

You could debate the default value of the option for a long time, but I think most people who are requesting this feature would be happy with it as a non-default option, if that's the easiest way to get it implemented.

For me, I want the hex literals to match Python's own format from the built-in hex function (e.g. print(hex(123)) gives 0x7b not 0x7B), which doesn't seem like an unreasonable thing to expect from a Python style guide / formatter.

[MichaReiser]

Thanks, you're right that it's almost time to start thinking about this. I don't have a lot of time right now, but my general expectation is that we'll stabilize all the changes currently in preview but not the ones in unstable, unless someone contributes a fix for the bugs that made those changes go into the unstable style.

Thanks. That helps to set expectations and plan. I'll close this issue because my question has been answered and I'm happy to join the Black 2025 style guide discussion (please tag me if you don't mind).