Skip to content

What are your plans for the Black 2025 style guide? #4501

Description

@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):

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:

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

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.

Activity

  1. JelleZijlstra commented on Oct 23, 2024

    @JelleZijlstra
    Collaborator

    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.

  2. Montg0mery commented on Oct 23, 2024

    @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.

  3. MichaReiser commented on Oct 24, 2024

    @MichaReiser
    Author

    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).

  4. hugovk commented on Dec 3, 2024

    @hugovk
    Contributor

    It's nearly 2025! 😲

    Time to prepare the 2025 style?

  5. JelleZijlstra commented on Dec 3, 2024

    @JelleZijlstra
    Collaborator

    Yes...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    T: styleWhat do we want Blackened code to look like?

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions