Setting the 2024 stable style #4042
Comments
|
My vibes:
|
|
My ¢2 as a Black user:
|
|
Thanks, this is great! We should try to make a I haven't thought too hard about each change, but a few thoughts:
|
|
On string_processing: We have been using it internally (Google) since the beginning of this year and it has been working well for us. So I'm motivated to keep this and help graduate it to the stable style (too late for the 2024 stable style though).
This is a good strategy, I think we can split string_processing into a few separate style changes. Moving all of them at once is hard to reason about and is too disruptive. |
|
I tested preview on a code base of mine, and it mostly looked good. The only change I was really surprised by was from string processing; the same issue as #3663 and #3210 . A little testing showed that it's from the string_paren_strip transformer. I like the idea of that part of string_processing, but that's a pretty ugly downside. It seems like it's stripping the parentheses and then re-inserting them at a worse place, which is consistent behavior with non-preview style if I manually remove the parentheses first. Not strictly a problem with string_paren_strip, I guess, but not great. For hug_parens, I like it in theory but it does feel less consistent than the current behavior, at least in some cases. I'm not totally sure about it. I can understand why you'd compare it and multiline_string_handling, but I don't see any issues with the latter - that one looks great to me. I think that parenthesize_conditional_expressions is a big improvement for conditionals in the original context of function arguments, but I don't think I like what it's doing in other contexts. |
|
I started putting together a PR to prepare an alpha for the 2024 stable style, and here's a few thoughts:
|
|
Is there a chance of If it means anything it was also quickly picked up by It seems to me to be controversial as it would create a lot of diffs across projects, but doesn't change styling in any way that users would say "hey, what's black doing there". I would really like to see this change make it in to standardize these newlines across the projects I work on (and which don't want to run with |
|
@DanielNoord yes, that one is expected to go in (unless either lots of people speak up and say they don't like it, or we discover bugs caused by it). |
|
I'm still writing it up but we track Ruff's preview style compatibility in astral-sh/ruff#8678 Regarding MULTILINE = """
foobar
""".replace("\n", "")and we've generally received positive feedback. I haven't yet come around to implement the special casing inside call expressions. So I can't say how people feel about that. I personally like Ruff formats long dict values slightly different from black ( I'll share more feedback when I had time to take a closer look at the changes and thanks for drafting this up, it helps to understand how Black's styleguide will change. |
|
Release notes states the following regarding #3445 :
Isn't this a topic for this discussion? |
|
@takanakahiko I'm not sure exactly what you're asking. This issue is definitely the right place to discuss what should go into the 2024 stable style. The default is that everything in the preview style will move to stable, unless there's some reason not to. As discussed above, string processing (which is what #3445 affects) probably will not go into the 2024 stable style because there are many open bugs around it. |
|
@JelleZijlstra I may have had a problem with my English, sorry. I thought all Preview styles were listed because it said the following.
However, I was concerned that my interest #3445 was not listed, so I asked my question. Thanks for the answer. |
Fixed the crash, feel free to tag me if any other issues with either of the type-hint features I added cause any other problems :) |
|
Here is my feedback. TLDR: I like the changes with I was testing black 23.11.0 with I like this idea with Ellipsis on the same line (there is no longer a need to exclude it from coverage) - def decode(self, data: Any) -> T: # pragma: no cover
- ...
+ def decode(self, data: Any) -> T: ...It found an unnecessary string concatenation: raise ValueError(
- f"Time zone {s} must be either UTC " f"or in format UTC[+-]hh:mm"
+ f"Time zone {s} must be either UTC or in format UTC[+-]hh:mm"
)This became more readable: schema = JSONObjectSchema(
- additionalProperties=_get_schema_or_none(
- instance.derive(type=args[1]), ctx
- )
- if args
- else None,
- propertyNames=_get_schema_or_none(
- instance.derive(type=args[0]), ctx
- )
- if args
- else None,
+ additionalProperties=(
+ _get_schema_or_none(instance.derive(type=args[1]), ctx)
+ if args
+ else None
+ ),
+ propertyNames=(
+ _get_schema_or_none(instance.derive(type=args[0]), ctx)
+ if args
+ else None
+ ),
)Special thanks for this change, I like it a lot: serialize_by_alias: Union[
- bool, Literal[Sentinel.MISSING]
- ] = Sentinel.MISSING
- namedtuple_as_dict: Union[
- bool, Literal[Sentinel.MISSING]
+ bool, Literal[Sentinel.MISSING], float, List[str]
] = Sentinel.MISSING
+ namedtuple_as_dict: Union[bool, Literal[Sentinel.MISSING]] = (
+ Sentinel.MISSING
+ )What interesting is that ruff turns all this changes back, so all the credits go to black! |
|
Some feedback to the most recent changes to It seems that Black now recursively collapses (hugs) parentheses. We believe that this makes the code harder to read. Like here, it becomes difficult to tell which parentheses belong together )
)
if commented_entity:
- entity_map = CommentedMap(
- [(entity["entity"], entity["value"])]
- )
+ entity_map = CommentedMap([(
+ entity["entity"],
+ entity["value"],
+ )])
entity_map.yaml_add_eol_comment(
commented_entity, entity["entity"]
)
entities.append(entity_map)
else:
entities.append(
- OrderedDict(
- [(entity["entity"], entity["value"])]
- )
+ OrderedDict([(
+ entity["entity"],
+ entity["value"],
+ )])
)
else:
entities.append(But maybe that's just us not being used to that style. We were surprised to learn that Black now leaves the following snipped as is self._edits.append(
{"operation": "update", "id": index, "fields": list(fields), "region_fields": []}
)and doesn't format it to self._edits.append({
"operation": "update", "id": index, "fields": list(fields), "region_fields": []
})We prefer the second style because it leads to fewer changes when the length of the dictionary changes: self._edits.append({
"operation": "update",
"id": index,
"fields": list(fields),
"region_fields": [],
"loooger": "more",
})The parentheses and the first entry remain unchanged. Making it easier to spot the differences self._edits.append({ "operation": "update", "id": index, "fields": list(fields)})Again, the opening parentheses remains unchanged. It also feels more consistent with function calls where the parentheses (for good reasons) are kept on the first line: self._edits.append(
"operation", "update", "id", index, "fields", list(fields), "region_fields", []
)
Ruff doesn't implement Black's preview style yet. But yes, all credit for Ruff's style guide goes to Black, because Ruff follows Black's style guide. |
|
Replying to a few recent posts (including my own):
I misread something here, we already use lowercase. We should keep this in the 2024 style.
This actually looks concerning to me, because Black shouldn't go around removing comments. I can't reproduce this behavior, though. @MichaReiser thanks for the feedback! I think we'll exclude the hug_parens changes from the stable style this time because they came in late of the year and are likely to be controversial. Could you perhaps make a new issue? |
I'm pretty sure they meant that they removed the comment themselves. |
Yes, you're right. Black didn't remove the comment, I did. |
|
I plan to create PRs for larger projects using Ruff's formatter and ask them for feedback on the preview style once I've implemented all preview styles (some of them are tricky to get right!). It will probably be January until I find the time but I'll share the feedback here if you're interested (and/or maybe that's something you want to do as well)? |
|
Thanks, that's great! I won't have much time until January. I'm planning to put out an alpha release today or tomorrow with the new style, then finish things up in January. |
|
Hello, we’re engineers from Lyft and want to provide some initial feedback from testing out the new features from the alpha (https://github.com/psf/black/releases/tag/24.1a1): Bulk of the observed changes have been parenthesizing conditional expressions, splitting RHS of assignments, wrapping long dict values in parentheses, and docstring formatting which have looked good overall and are big improvements in readability. From the changelog, it shows that parenthesizing conditionals may or may not be included, but so far, we definitely liked this feature overall. We found this case where black added parentheses around a dictionary (after Wanted to confirm if this formatting is due to Also, is there a sense when to expect the major release/2024 stable style (ie) mid or end of Jan)? We’ll continue to do some more testing and provide additional feedback towards the end of the year. Thanks for all of the development work! |
|
In this case the trailing/inline comment is moved to the wrong line: a = "".join(
(
"", # comment
"" if True else "",
)
)becomes a = "".join((
"",
"" if True else "", # comment
)) |
## 23.12.0 ### Highlights It's almost 2024, which means it's time for a new edition of _Black_'s stable style! Together with this release, we'll put out an alpha release 24.1a1 showcasing the draft 2024 stable style, which we'll finalize in the January release. Please try it out and [share your feedback](psf/black#4042). This release (23.12.0) will still produce the 2023 style. Most but not all of the changes in `--preview` mode will be in the 2024 stable style. ### Stable style - Fix bug where `# fmt: off` automatically dedents when used with the `--line-ranges` option, even when it is not within the specified line range. (#4084) - Fix feature detection for parenthesized context managers (#4104) ### Preview style - Prefer more equal signs before a break when splitting chained assignments (#4010) - Standalone form feed characters at the module level are no longer removed (#4021) - Additional cases of immediately nested tuples, lists, and dictionaries are now indented less (#4012) - Allow empty lines at the beginning of all blocks, except immediately before a docstring (#4060) - Fix crash in preview mode when using a short `--line-length` (#4086) - Keep suites consisting of only an ellipsis on their own lines if they are not functions or class definitions (#4066) (#4103) ### Configuration - `--line-ranges` now skips _Black_'s internal stability check in `--safe` mode. This avoids a crash on rare inputs that have many unformatted same-content lines. (#4034) ### Packaging - Upgrade to mypy 1.7.1 (#4049) (#4069) - Faster compiled wheels are now available for CPython 3.12 (#4070) ### Integrations - Enable 3.12 CI (#4035) - Build docker images in parallel (#4054) - Build docker images with 3.12 (#4055)
|
@yuhrichard @cgohlke |
|
I really like hug_parens_with_braces_and_square_brackets, hope it gets merged in 2024 so that we don't have to wait a year. As for multiline string processing, I am not a big fan, I find implicit concatenation of string literals somewhat confusing and would prefer single (but long) literal. One case where I find it actively worse then it were: Original: Old black: (clunky but ok) New black (with preview): == is so unnoticable here Ideal result (with new hugging style) considering we need to have splitting Probably good enough is this: Also, I think multiline string should almost always be in parens (except in cases where it's already in cases when they are already in parens from the function call. There are cases when it's not this way (in asserts as above), in list comprehensions: original: black with preview |
|
I hope this is the correct place to comment on this. I "accidentally" ran the alpha version on my project and I think the new # Before
class Parser(typing.Protocol):
def set_defaults(self, **kwargs: typing.Any) -> None:
... # pragma: no cover
# After
class Parser(typing.Protocol):
def set_defaults(
self, **kwargs: typing.Any
) -> None: ... # pragma: no cover
This doesn't seem to me to be much of an improvement in readability. I think I understand the intent of the rule to move the elipsis onto the same line as the |
|
@phlogistonjohn that's issue #3872. As I wrote on the issue, I think it's still a net positive on balance, but there's definitely some risk, especially in cases where there is a comment after the |
|
@AlexeyDmitriev string splitting won't be in the 2024 stable style. (And for everyone commenting, thanks for your feedback!) |
|
@JelleZijlstra thanks for your feedback. |
|
@JelleZijlstra I was looking at #4106, Do I understand correctly that parens hugging will not make it either? |
|
We'll publish it by the end of the month and the hugging changes will not be included. |
|
Sorry if these pieces have already been covered, but I ran the preview style (from 24.1a1) over a small portion of Meta's codebase and have some feedback. Most of the style changes seem like a positive change, but I think the changes to collapsing/compacting elements and especially multiline strings is a net-negative. First some changes I'm happy to see: # before
for (a, b) in things:
...
# after
for a, b in things:
...# before
value: Optional[
int
] = None # some really long comment
# after
value: Optional[int] = (
None # some really long comment
)Love it! # before
func(
arg1,
"long string"
if condition
else "other string",
)
# after
func(
arg1,
(
"long string"
if condition
else "other string"
),
)Much clearer, exactly how I would have rewritten it myself! 💜 Now, some examples where I think the changes result in less-readable code, particularly where black takes aligned triple quotes and then unaligns them: # before
Thing(
"""
value
"""
)
# after
Thing("""
value
""")or worse: # before
VALUE = [
Thing(
"""
value
"""
)
]
# after
VALUE = [Thing("""
value
""")]# before
func(
(
value
+ """
something
"""
),
argument,
)
# after
func(
(value + """
something
"""),
argument,
)Not pretty, and not really any more readable than before? ¯\(ツ)/¯ Is that related to the "paren hugging" you mentioned, or is this still scheduled for the 2024 style? |
Maybe not, because I just found this change as well: # before
def foo():
result = (
"""
something
"""
+ value
)
# after
def foo():
result = """
something
""" + valueDistinctly less readable IMO. |
|
Update:
|
and others
See issue for 2023 here: #3407
Here's what this issue is:
--previewIssues tagged with(sorted these out–Jelle)previewI haven't yet associated with a feature: Preview style: Preserve empty lines between async def and async for #3614 and string_processing: makes it impossible to use a comment to ignore a static type violation #3802Here's the current call to action:
--previewand let us know your thoughts!For many of the changes, diff-shades logs have expired. We should find a way to keep these around for longer!
It's currently November, so there's still time to make more uncontroversial changes and hopefuly iron out some issues in the not uncontroversial ones.
Not uncontroversial
string_processing
This one is controversial, vast majority of preview style issues are related to string processing
Open issues I believe are caused by string_processing: #2334, #2314, #3466, #3497, #3409, #3424, #3428, #3210, #3410, #3747, #3665, #3663, #2553, #3855, #3802
hug_parens_with_braces_and_square_brackets (#3964, #3992)
Causes O(10000) changes, although counting lines changed is unfavourable to this change.
A very substantial change in style for Black. We can't revert once it's in stable.
Outstanding crash: #4036
parenthesize_conditional_expressions (#2278)
Causes O(1000) changes. Need to look at diff
Has unfortunate interactions with comments: #3555wrap_long_dict_values_in_parens (#3440)
Causes O(100) changes. Need to look at diff
Outstanding crash: #3758Report of worse splitting: #3452
Unnecessary nesting: #4129Removes parentheses: #4158
multiline_string_handling (#1879)
Causes O(1000) changes. Need to look at diff
Maybe has some synergy with
hug_parens_with_braces_and_square_brackets.Unfortunate white space preservation: #4159
dummy_implementations (#3796)
I can't find up-to-date diff-shades, but maybe O(1000) changes
Requires a change in flake8 config: #3887
Can result in an extra line, but no change expected to be made: #3872
prefer_splitting_right_hand_side_of_assignments (#3368)
Causes O(100) changes.
hex_codes_in_unicode_sequences (#2916)
Causes O(100) changes
Open issue whether lowercase or uppercase is better #3568
allow_empty_first_line_before_new_block_or_comment (#3967)
Causes O(1) changes.
This change itself is fine, but it's related to a controversial and churn causing change in 2023 style. I think we should probably revert that 2023 change; I posted a longer issue about this over here #4043
parenthesize_long_type_hints (#3899)
Causes O(100) changes
module_docstring_newlines (#3932)
Causes O(100) changes
Uncontroversial
respect_magic_trailing_comma_in_return_type (#3916)
O(10) changes.
Shouldn't affect existing formatting too much, unless there's a buggy trailing comma
All changes in diff-shades are incidental, but are good and what you'd expect Black to do
no_blank_line_before_class_docstring (#3692)
O(100) changes. Makes consistent with function behaviour
Blank lines have been a little controversial, but I think this should be totally fine
wrap_multiple_context_managers_in_parens (#3489)
O(100) changes. Naively, looks great to me
fix_power_op_line_length (#3942)
O(10) changes. A bug fix
add_trailing_comma_consistently (#3393)
O(1) changes. A bug fix
skip_magic_trailing_comma_in_subscript (#3209)
O(1) changes. A bug fix, affects a non-default option
blank_line_after_nested_stub_class (#3564)
Only affects stubs, adds some blank lines in an uncommon case
blank_line_between_nested_and_def_stub_file (#3862)
Only affects stubs, adds some blank lines in even less common case
accept_raw_docstrings (#3947)
O(1) changes. Just a bug fix
long_case_block_line_splitting (#4024)
0 changes. Seems strictly good
walrus_subscript (#3823)
0 changes. Straightforward style change
improved_async_statements_handling (#3609)
0 changes. More consistent
single_line_format_skip_with_multiple_comments (#3959)
0 changes. Makes life better
The text was updated successfully, but these errors were encountered: