#black-formatter
1 messages ยท Page 3 of 1
How much faster mypyc-compiled black is compared to interpreted version?
Do you have some benchmarks?
2x IIRC
https://ichard26.github.io/blog/2022/05/compiling-black-with-mypyc-part-1 @slow ibex might wanna read this
I spent a COVID summer (and then some) integrating mypyc into Black to double performance. How was it?
unfortunately, for whatever reason pre-commit doesn't use wheels and everyone seems to run black via pre-commit ๐ฆ
I guess that's what https://github.com/psf/black/issues/3405 is about
assert xxxxxxxxx.xxxxxxxxx.xxxxxxxxx(
xxxxxxxxx
).xxxxxxxxxxxxxxxxxx(), (
"xxx {xxxxxxxxx} xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
)
Running black --preview on this file results in error: cannot format xxxxxx.py: Unable to match a closing bracket to the following opening bracket: .
This is a regression in 22.12.0. It bisects to #3370, cc @yilei.
Description
The but is in the get_leaves_inside_matching_brackets on the third line below:
assert xxxxxxxxx.xxxxxxxxx.xxxxxxxxx(
xxxxxxxxx
).xxxxxxxxxxxxxxxxxx(), (
"xxx {xxxxxxxxx} xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
)
Including the invisible paren, third line is ).xxxxxxxxxxxxxxxxxx()), (, that it has a matched pair then an unmatched closing paren afterwards. This PR ensures the returned leaves are actually matched.
...
Description
mypyc reports error src/black/__init__.py:670:29: error: Incompatible types in assignment (expression has type "Dict[Any, PathSpec]", variable has type "Optional[PathSpec]") [assignment] (https://github.com/isac322/docker_image_blackd/actions/runs/3663490540/jobs/6193303572#step:7:1640)
Checklist - did you ...
- [ ] Add an entry in
CHANGES.mdif necessary? - [ ] Add / update tests if necessary?
- [ ] Add new / update outdated documentation?
Thanks! I think this started failing because pathspec just did a release adding a py.typed file: https://github.com/cpburnz/python-pathspec/blob/master/CHANGES.rst
1f7f6de Fix type annotation for gitignore pathspec (#3416) - isac322
I want want to immediately see on the output (stdout) what has changed after a black run.
--diff stops writing back the file.
So it would require an arduous tee-ing to a temp file and risky patch script; or running black twice.
It could be done by:
- double verbose:
-vv --diff+--diff --write
....
This shouldn't be merged before 2023 (in case we want to do another 22.12 release) and shouldn't be merged until we have consensus in #3407. I'm opening it so I can evaluate the effect of the draft 2023 style without the obviously problematic bits.
Closes #3407
- Clean up comments.py preview mode
- Clean up preview in init.py
- clean up normalize_invisible_parens preview
- more in linegen.py
- annotation_parens
- empty_lines_before_class_or_def_with_leading_comments
- handle_t...
$ black -c 'def this_is_so_dumb() -> (please := no): ...'
def this_is_so_dumb() -> (please := no):
...
$ black --preview -c 'def this_is_so_dumb() -> (please := no): ...'
def this_is_so_dumb() -> (please := no): ...
error: cannot format : Cannot parse: 1:32: def this_is_so_dumb() -> please := no:
$ black --version
black, 22.12.0 (compiled: yes)
Python (CPython) 3.9.14
Found this in CI for #3418, cf. #3407.
Seems like a result of #2990, cc @jpy-git.
Broader learn...
$ black --fast -c '''
try: pass
except (a := 1) as (b := why_does_this_exist): pass
'''
try:
pass
except (a := 1) as (b := why_does_this_exist):
pass
$ black --preview --fast -c '''
try: pass
except (a := 1) as (b := why_does_this_exist): pass
'''
try: pass
except (a := 1) as (b := why_does_this_exist): pass
error: cannot format : Cannot parse: 3:9: except a := 1 as (b := why_does_this_exist):
$ black --version
black, 22.12.0 (compiled: yes)
Python (CPython) 3....
Describe the style change
Em,actually i dont know how to configure black in file.
I use python3.7.9 before,but after i updated to python3.8.10,the style i used is gone........
I have adapted to the style used before.
I want to change the "=" style in a function,I want to add space(other place is normal)๏ผi think it is better.
Examples in the current Black style
.
Code:
print(
"Long lines with inline comments which are apart of (and not the only member",
"Arg #2",
"Arg #3",
)
On black 22.12.0:
% black --diff tests/data/miscellaneous/long_strings_flag_disabled.py -l 8
error: cannot format tests/data/miscellaneous/long_strings_flag_disabled.py: INTERNAL ERROR: Black produced different code on the second pass of the formatter. Please report a bug on https://github.com/psf/black/issues. This diff might be helpfu...
Code:
def multiline_backslash_2():
"""
hey there \ """
On Black 22.12.0:
% black --diff tests/data/miscellaneous/docstring_no_string_normalization.py -l 18
error: cannot format tests/data/miscellaneous/docstring_no_string_normalization.py: INTERNAL ERROR: Black produced code that is not equivalent to the source. Please report a bug on https://github.com/psf/black/issues. This diff might be helpful: /var/folders/3b/k964cnv10097wzj3h7w07fww0000gp/T/blk_jh8...
Whelp, looks like I got a fair bit of reading later today
summary: don't set line length to 1
I'm finding this by running all test cases with --line-length=1, a generalization of psf/black#3423
there's 10 more failures I'm looking at
oh gosh that's horrible
Found with a variation on #3423 that runs tests in pyi mode.
def x():
"""first line----------------------------------------------------------------------
second line----------------------------------------------------------------------"""
Crashes with Black 22.12.0:
% black --diff tests/data/preview/docstring_preview.py -l 6
error: cannot format tests/data/preview/docstring_preview.py: INTERNAL ERROR: Black produced different code on the second pass of the formatter. Please report a bug on https://github.com/psf/bla...
oh all these actually only crash in preview mode, missed that because I was running inside the black repo
Oh nice.
Interesting
inline_comments_func2(
" this part does not fit into a single line? "
# x
"it into parts that fit in line length.",
)
On 22.12.0:
% black --diff tests/data/preview/long_strings.py -l 4 --preview
error: cannot format tests/data/preview/long_strings.py: INTERNAL ERROR: Black produced code that is not equivalent to the source. Please report a bug on https://github.com/psf/black/issues. This diff might be helpful: /var/folders/3b/k964cnv10097wzj3h7w07fww0...
Why would you want to set line length to 6?
I think you can add restriction to that option (for example, line length must be >= 10) to prevent similar crashes in future
Reply to this*
How black behaves when variable name is longer than line length? Give up and leave it as is?
because it's a great way to find crashes :). More seriously, these crashes likely also appear with reasonable line lengths if you add enough indentation
granted, 20 levels of indentation is pretty crazy too
yes, it gives up
ok this is all, most of the failing test cases were duplicates
Thanks for landing my mypyc pr!
Currently, Black checks that the AST of its input and output is the same (except for some narrow exceptions). This is a powerful feature that has caught many bugs (e.g. most recently #3428).
Could we add more similar checks?
- Comment equivalence. We have had bugs in the past where certain comments get removed. Perhaps we could add a simple check that extracts all comments from the input and output (normalized for leading/trailing whitespace) and asserts that the input and output have t...
yeah but
don't know if it's worth opening an issue, but it looks like https://black.readthedocs.io/en/stable/ still points to 22.10 (cleared cache on my end)
I can do it if you're busy
It might actually be faster to spin up a GitHub Codespaces to so this because my main machine is refusing to connect to WiFi
don't worry about it, I'm just eating lunch first
Ah alright. Bon appetit!
Is it still not done automatically?
it is
it is but since the mypyc jobs are busted, it doesn't run
but the macos wheel jobs failed
ah
we're waiting on hatch-mypyc to properly support cross-compilation for macOS
stable branch is updated
Fixes #3320. Followup from #3044.
Code looks fine in general, but this code is hard to grok so let's see what diff-shades has to say first.
idea: I'd like to release a version of psf/black#3418 as 23.1a1 so people can try the new stable style more easily
I like that
I also plan on writing a short blog post based on your issue highlighting the changes as a call for feedback
definitely best to allow people to try it themselves though
that's great! would you mind reviewing https://github.com/psf/black/pull/3423 since that would unblock a few more parts of the new stable style?
I think with that and #3430 merged we can get a solid draft
Yeah, will do so as soon as I have time.
!remind 20H
Your reminder will arrive on <t:1670874990:F>!
<!--
Please make sure that the bug is not already fixed either in newer versions or the
current development version. To confirm this, you have three options:
- Update Black's version if a newer release exists:
pip install -U black - Use the online formatter at , which will use
the latest main branch. - Or run Black on your machine:
- create a new virtualenv (make sure it's the same Python version);
- clone this repository;
- run
pip install -e .[d]; - run `...
Describe the style change
Lambdas used as default parameters for functions look really ugly when the function parameter is exploded (e.g. via a typehint being too long
Examples in the current Black style
class Foo:
def bar(
self,
baz: typing.Callable[
# long typevar name (and this comment) causes
# declaration to be exploded
[SpecialisationT, SpecialisationT], SpecialisationT
] = lambda i, j: ...
plans to include https://github.com/psf/black/pull/2885 in the next stable release?
actually nvm ignore me
9bbe11d Bump pypa/cibuildwheel from 2.11.2 to 2.11.3 (#... - dependabot[bot]
abd2b25 Bump furo from 2022.9.29 to 2022.12.7 in /docs ... - dependabot[bot]
Describe the bug
When using --preview, this input causes error message "Unable to match a closing bracket to the following opening bracket: )". No issues when running without --preview
Looks similar to #3414, but I can still reproduce this issue in main branch.
To Reproduce
from typing import Generic, TypeVar
T = TypeVar("T")
class VeryLongClassNameWithAwkwardGenericSubtype(Generic[T]):
pass
def something(
argument: (
"VeryLongC...
Here's your reminder: that's great! would you mind reviewing https://github.com/psf/black/pull/3423 since that would unblock a few more parts of the new stable style?
[Jump back to when you created the reminder](#black-formatter message)
On second look, this code looks suspicious.
Actually this seems fine on a third look.
7d062ec Do not put the closing quotes in a docstring on... - JelleZijlstra
oh diff-shades on main is broken, that's ... not great
will look into it tomorrow
Describe the bug
If a condition statement is wrapped in # fmt: off/# fmt: on, Black crashes with a parse error on the subsequent line.
The crash only occurs if the # fmt: off comment is indented the same as the wrapped condition.
To Reproduce
The following minimal code breaks parsing with Black 22.10 and later:
def do_something(x, y):
if x:
return x
# fmt: off
elif y:
# fmt: on
return y
And run it with these arg...
<!--
Please make sure that the bug is not already fixed either in newer versions or the
current development version. To confirm this, you have three options:
- Update Black's version if a newer release exists:
pip install -U black - Use the online formatter at , which will use
the latest main branch. - Or run Black on your machine:
- create a new virtualenv (make sure it's the same Python version);
- clone this repository;
- run
pip install -e .[d]; - run `...
Description
Fixes #3436.
Note that the # fmt: on line is always normalized to the next statement so its indentation is moved in this case. This isn't ideal, but at least it shouldn't crash.
Checklist - did you ...
- [x] Add an entry in
CHANGES.mdif necessary? - [x] Add / update tests if necessary?
- [x] Add new / update outdated documentation?
Is it clear when the secondary format runs are the ones erroring out? I just don't want this to confuse contributors unfamiliar with our testing setup. I'm not happy this quadruples the runtime of the test_format.py tests (12s -> 45s), but c'est la vie.
I apologise in advance if I forget my manners. I only have time for Black when it's late and I'm tired. It's harder for me to maintain the same positive chirpy mood/tone I usually try to bring.
I feel like we should write developer docs on how fmt: off/on/skip work. The logic as-is is already complicated as heck and the edge cases are incredibly confusing sometimes...
Also technically this is invalid use of # fmt: off/on but that's just a limitation of Black since there's no way to represent a # fmt: on at the right indent level right after a dedent.
yeah OK I got carried away being a bit bored here: https://github.com/psf/black/issues/3405#issuecomment-1350392836
I 100% would not support using something as hacky as this
It is almost midnight now so I'm done for tonight. I'll pick up where I left off tomorrow.
Description
This PR changes the preview style:
- Wraps long values in dict literals in parentheses. Fixes #620. Fixes #808.
- Correspondingly, parentheses around short values in dict literals are removed.
- In preview string processing, long lambda string values are now wrapped in parentheses.
- Wrapping dict values happens to fix #3117 where implicitly concatenated r-string dict values crash in string processing. Fixes #3117
Usually I'd like to keep the PR's scope min...
<!--
Please make sure that the bug is not already fixed either in newer versions or the
current development version. To confirm this, you have three options:
- Update Black's version if a newer release exists:
pip install -U black - Use the online formatter at , which will use
the latest main branch. - Or run Black on your machine:
- create a new virtualenv (make sure it's the same Python version);
- clone this repository;
- run
pip install -e .[d]; - run `...
thanks, just noticed two typos
a282181 Fix a crash when a colon line is marked between... - yilei
I've been feeling incredibly tired today and I wasn't able to bring myself to work on Black. I'm sorry about that, hopefully I feel better tomorrow.
Thanks again Jelle for keeping the show running while I'm gone.
Describe the style change
Examples in the current Black style
tests = [
(
BusinessHour(),
{
Timestamp("2014-07-04 15:00")
+ Nano(5): this_is_a_very_long_function("2014-07-04 16:00"),
Timestamp("2014-07-04 16:00")
+ Nano(5): this_is_a_very_long_function("2014-07-04 16:00"),
Timestamp("2014-07-04 16:00")
- Nano(5): this_is_a_very_long_function("2014-07-04 16:00"),
...
black ./ --check --verbose --preview on my terminal says All done! โจ ๐ฐ โจ 18 files would be left unchanged.
but in github action it says
Oh no! ๐ฅ ๐ ๐ฅ 6 files would be reformatted, 11 files would be left unchanged. Error: Process completed with exit code 1.
nevermind black on my pip was a bit outdated
<!--
Please make sure that the bug is not already fixed either in newer versions or the
current development version. To confirm this, you have three options:
- Update Black's version if a newer release exists:
pip install -U black - Use the online formatter at , which will use
the latest main branch. - Or run Black on your machine:
- create a new virtualenv (make sure it's the same Python version);
- clone this repository;
- run
pip install -e .[d]; - run `...
Looked over diff-shades again and everything looks good.
658c8d8 Improve long values in dict literals (#3440) - yilei
are you updating the preview issue with the recent merges?
I think recent merges shouldn't go into the 2023 stable style
I'm also tempted to review these PRs, but there's no way I have time for that right now ๐
since users won't have time to try them out in preview style
alright, sounds good
Description
This bug appears to have existed earlier. But it's now triggered on the added test after https://github.com/psf/black/pull/3440 on the complex dict value.
The infinite recursion happens when getting the second_opinion. Example traceback:
Traceback (most recent call last):
File "/Users/yileiyang/github.com/yilei/black/src/black/__init__.py", line 1077, in format_str
dst_contents = _format_str_once(src_contents, mode=mode)
^^^^^^...
Thanks for noticing and fixing!
7816393 Fix an infinite recursion error exposed by #344... - yilei
I'll try to start working on Black again tomorrow. This week has been pretty awful, but I can make it work.
Description
This patch changes the preview style so that string splitters respect Unicode East Asian Width property. If you are not familiar to CJK languages it is not clear immediately. Let me elaborate with some examples.
Traditionally, East Asian characters (including punctuations) have taken up space twice than European letters and stops when they are rendered in monospace typeset. Compare the following characters:
abcd...
- We can run everything now like all other stable versions of Python
- test in a 3.11 vent:
/tmp/tb/bin/tox -e py311,ci-py311
py311: OK (28.99=setup[7.90]+cmd[5.29,0.66,6.94,6.08,1.89,0.24] seconds)
ci-py311: OK (30.33=setup[3.20]+cmd[3.66,0.31,17.43,4.60,0.90,0.23] seconds)
congratulations :) (59.35 seconds)
@dense jungle or anyone else around - Anything else burning I can try help with for 23.1.0 release?
Got some cycles this weekend
Sorry I've been awol
Snow has been good and eating free time ๐
Describe the bug
After installing black using pip inside venv running it results in 'ModuleNotFoundError' No module named 'tomli' exception beeing raised:
To Reproduce
- Create new virtual environment and activate it
python -m venv venv
and
.\venv\Scripts\activate.ps1
pip install blackblack --version
output:
Traceback (most recent call last):
File "C:\Users\PC1080Ti\AppData\Local\Programs\Python\Python38\lib\r...
did you see https://github.com/psf/black/issues/3407 ?
(I've seen nothing - Been not paying attention except to email subject lines sorry)
Like when I saw complete 3.11 I was like damn I haven't done that I suck ... haha
no snow down here ๐ฆ have fun up in the Sierras!
Do you come up here to ski? We should do dinner / go ski if you do
(I'm in South Lake)
Reading all now and will see if there is anything I can help with
haven't in a couple of years, I've been going to Utah where a friend of ours has a house
would be great if you could run my branch from https://github.com/psf/black/pull/3418 on FB code and see if there's anything you don't like
though I need to update that branch a little
Ok - lets see if anything else to update on that branch and I'll put an hour in my calendar for Monday AM to do this on FB code (not on work laptop right now and that's a trip upstairs :P)
Why is "Remove trailing newlines after code block open" (#3035) controversal?
Wow, experimental string processing still very flaky ๐ That was one I'd be keen but seems it need a lot of work and stress testing. I'll see if it blows up on FB code too
I also agree, lets backout the super flaky parts maybe and just move it into --preview ...
Man diffshades does a lot - quite impressive what it tests โค๏ธ
maybe it's not! it just causes a lot of changes so I wanted to call it out in case people don't like it
Seems sane to me. I dislike the useless empty line that we have all left before ...
yes great work by @bright glacier ๐
I'm so lazy writing python now. I ram shit all on one line I know black will fix ๐
oh hi :)
I'm not even writing Python anymore lol, I've been mostly writing JS ๐
front-end only
I've been writing lots of Rust ๐ฆ
I don't have access to a backend so more websites on GitHub Pages.
Last javascript I wrote was many jobs ago and jquery in the early 2000s. I'm old ๐
It's not a terrible language, but it takes getting used to
the differences in the core data structures cause me quite a bit of trouble
a little bit, I'm just not a fan of the friction it adds to the edit-test cycle.
Looks good to me and well tested + documented.
Can we maybe add a f""" multiline string just to ensure it works / no regressions there in future please. I know I use them and sure many others do.
although that's probably fixable by adding a proper bundler like vite (that uses esbuild underneath)
You an async guru now writing JS?
flake8-bugbear finished as nothing-changed - sweet
I should enable preview on more of my projects ๐
I mean, I haven't been writing anything major in JS. Promises are nice to work with though
Oh yay, aiohttp finally supports 3.11 natively
Was going to approve that, but that also works haha
I had @dense jungle blessing. One of you two is all I need ๐ But thanks.
Was nice of someone to nudge us!
.github/workflows/ci.yaml lines 16 to 17
# aiohttp by defaults builds with Cython, but it's not marked as a build dep so we'll skip it.
AIOHTTP_NO_EXTENSIONS: 1```
Ok - I'm gonna go preview some of my other OSS projects with 22.12.0
O nice, I did miss that. Thanks
Stamp is ready.
Get some CI time back hopefully
Nah that's my own repository
O, missed that. I dumb dumb
Surprisingly none of our dependencies have broken our CI on their dev branch in the past few months (that's what the repo checks)
diff-shades on main is unfortunately broken
probably best to fallback to interpreted when the compilation of the baseline revision fails as that's mostly out of our control
FYI I haven't used the match statement before so that's why I haven't reviewed psf/black#3426 yet
- "Continuing to next file after error downloading: " f"{url}"
+ f"Continuing to next file after error downloading: {url}"
That is a nice find from --preview
https://github.com/pypa/bandersnatch/pull/1313/files - Did well here cleaning up others code ๐
nice, I also like the part of ESP where it removes f from things that aren't f-strings ๐
Yeah, strange flake8 was not picking those up ...
maybe because it's part of an implicitly concatenated string
I'm thankful for the bot removing my troll VP like photo from these links ... haha
don't thank the bot that was me ๐
haha - You're now a bot.
I thought I was the one who removed it. We really are the same person, doing the same time at the same time :p
>>> from packaging.specifiers import Specifier
>>> s = Specifier("<3.11.0a7")
>>> s.contains("3.8")
True
>>> s.contains("3.8rc1")
False
>>> s.contains("3.8.8rc1")
False
>>>
I wonder if this is the cause for psf/black#3447 (although AFAIK the version comparison logic should allow prereleases)
>>> s.contains("3.8.8rc1", prereleases=True)
True
I'm just going to land this one, seems safe enough
yes, might be a bug in pip or something
I'll check the pip repository
Cool - TIL, I already have flake8 running --preview. Nice
Ok - I'm off to walk doggy. BBL - Will prob fix bandersnatch to move to latest packaging version later today so I can move to latest tox for my OSS work
the recent packaging release seems to have a few bugs FWIW
Ya, need to see if that's effecting bandersnatch or if I just have to move to new APIs. Will open / submit PRs if so either way ...
I should've clarified this was on my machine (which is probably underpowered at this point). On GHA CI, it's negligible.
And yes when you take the runtime of the rest of the test suite, it's not that bad.
thanks, once that's in I can turn return_annotations back on in my other PR, which should be enough to get a full working draft
https://paste.pythondiscord.com/iwixisuwab reproducible with the 3.9.0b1 build I have laying around (no idea why, I don't remember)
thanks for checking! did you find an existing pip issue? maybe we should ask the issue reporter to open one
I'm trying
tried a few searches on pypa/pip and didn't find anything
the python version environment marker logic is implemented in packaging AFAICT
I was able to repro too on 3.10.0rc1. I ran pip install -vvvvvv with a lot of vs but it said nothing about tomli
I'm checking packaging.markers.Marker, turns out you can pass it a custom environment
>>> m = Marker("python_full_version < '3.11.0a7'")
>>> m.evaluate({"python_full_version": "3.8.8rc1", "python_version": "3.8"})
False
>>> m.evaluate({"python_full_version": "3.8.8", "python_version": "3.8"})
True
src/packaging/markers.py line 227
def evaluate(self, environment: Optional[Dict[str, str]] = None) -> bool:```
hmm, I just upgraded packaging and both are returning true now
I wonder if this has been fixed already
ah nice, so maybe pip just needs to update its vendored copy of packaging
https://github.com/pypa/pip/blob/1463081f10de6bfad81afe0d68272e7c3bedbadf/src/pip/_vendor/vendor.txt#L6 yup the latest release is still on packaging 21.3
src/pip/_vendor/vendor.txt line 6
packaging==21.3```
I'd probably just simplify it to something like
tomli>=1.0.0;python_version<"3.11", no need to worry about 3.11 alphas now
Hugo said this in the PyPA server, seems reasonable
>>> m = Marker("python_version < '3.11'")
>>> m.evaluate({"python_full_version": "3.8.8rc1", "python_version": "3.8"})
True
>>> m = Marker("python_full_version < '3.11.0a7'")
>>> m.evaluate({"python_full_version": "3.8.8rc1", "python_version": "3.8"})
False
On packaging 21.3
I'm not familiar enough with the PEP 440 comparison rules to understand why this is though.
I have to go now. Will be back in a few hours.
159984a Check stability for both preview and non-previe... - JelleZijlstra
This prevents bugs due to pypa/packaging#522.
Fixes #3447.
Cool - So that branch ready for me to test Facebook code on?
not yet sorry, will do some more work on it later today
Yeah no hurries - Plan Monday anyways
the branch is in a good state now, plan is to cut a 23.1a1 release tomorrow so it's easier to test
I'll take a look at the 2023 stable style issue tomorrow. I already have, but I haven't looked at it in depth
hey folks, is this the right channel to ask for Black support? I'm trying to set up the GitHub action, but it fails with "Oh no! ๐ฅ ๐ ๐ฅ 14 files would be reformatted"
I've used the exact configuration listed here https://black.readthedocs.io/en/stable/integrations/github_actions.html
Consider the fluent interface
v = (
foo_dict
.setdefault("a", {})
.setdefault("b", {})
.setdefault("c", {})
.setdefault("d", {})
)
At the moment, black formats this into
v = (
foo_dict.setdefault("a", {})
.setdefault("b", {})
.setdefault("c", {})
.setdefault("d", {})
)
The reason for the decision to put the first method call on the first line is unclear to me.
The [docs](https://black.readthedocs.io/en/stable/the_bla...
Consider this code snippet
import datetime as dt
default_date = dt.date.today() - dt.timedelta(1) # my long comment appears here # fmt: skip
After running black in https://black.vercel.app/ this becomes
import datetime as dt
default_date = dt.date.today() - dt.timedelta(
1
) # my long comment appears here # fmt: skip
which I find really confusing and by far inferior to the original formatting. Note that black has formatted the code althou...
I cannot keep up with all the activity ๐
I think I'm done for now, though there are a few more PRs that could use another look. Maybe later
(I'm currently writing a blog post for 23.1a1, I'll promote it everywhere I can once it's up)
great, thank you! maybe we can also get ambv to call it out on Twitter
I have a twitter account if you haven't noticed
but yes his reach would be important
me too but I bet more people follow him ๐
@dense jungle did your PR effectively undo psf/black#3044 ?
My gut says no, but I'm getting confused with what was kept and what was not
Ah right, multiline docstrings
I think I'm running into a chrome rendering bug somehow
Oh huh, nothing that depends on ESP being enabled is turned on by default in 23.1a1, that includes change no.3 and no.17 (the wrapping implicitly concatenated strings in parentheses ones)
I should've known that earlier, but I forgot how they were implemented.
OK also no.4 is still preview only in the 2023 style since it's only relevant to ESP
โฏ git commit -S -m "Add Black 23.1a1 blog post draft"
codespell................................................................Passed
mdformat.................................................................Passed
trim trailing whitespace.................................................Passed
fix end of files.........................................................Passed
check yaml...........................................(no files to check)Skipped
[main 8cfd475] Add Black 23.1a1 blog post draft
1 file changed, 611 insertions(+)
create mode 100644 content/blog/2022-12-18-please-test-black-23.1a1.md
OK, it's been written. Now I just need to review it and also prepare psf/black#3407 for the extra attention it will soon get.
good call, I'll strike it in the post (along with 3 and 17 once I've verified)
and 14 too, that's ESP which ain't being promoted for sure
done
Oh, I almost forgot. Ofek fixed the mislabelled platform tags on macOS bug (pypa/hatch#672) ๐
Ideally we would've tested it out during cutting 23.1a1, but oh well. Hindsight is 20/20
maybe we'll get to make an a2
probably
or make a 22.12.1
people are going to get opinionated real quickly once word gets out we're touching the stable style :)
huh maybe psf/black#3162 does work without ESP, I am seeing it triggered on mypy code
what changes is it making?
I'm surprised since AFAIK it's tied to the Preview.string_processing flag which still exists
hm somehow ESP is actually being applied, I wonder what I did wrong
oh I bet I already had reformatted my checkout in preview style before
are you sure the preview style isn't being enabled in some user/project configuration you have?
(I confused myself by doing my testing in the black repo which has the preview style enabled
)
yes, that was really annoying when I was reporting my line length 1 bugs last week. I was thinking of proposing an "isolated mode" that ignores config files
also, added https://github.com/psf/black/labels/C%3A preview style so we can track problems with the preview style
The crash reproes on 22.12.1 but appears to be fixed on main; add
a test to make sure.
Description
Checklist - did you ...
- [ ] Add an entry in
CHANGES.mdif necessary? - [ ] Add / update tests if necessary?
- [ ] Add new / update outdated documentation?
@dense jungle if you want to review before push it to main: ichard26/ichard26.github.io#5
I'm sure my punctuation and grammar are rough since I wrote it in bit of a rush ๐
taking a look, the first few paragraphs look good ๐
I added a brief header to your "setting the 2023 stable" issue for those jumping in without much context
Ah yeah, I forgot about ordering the changes in a meaningful way
I always end up googling half a dozen grammar questions every time I write a post :)
And it's live! https://ichard26.github.io/blog/2022/12/black-23.1a1/
We just released Black 23.1a1 with the first draft of the 2023 stable style, please try it out and let us know your feedback and concerns.
Tweet has been posted https://twitter.com/sichard26/status/1604648727578386439
... did Twitter break their embeds?
We still have -t py 34 and -t 35 AFAIK
it's probably time to stop caring?
I would be in favour of removing support in 2023
Describe the style change
I'm looking at differences between 22.8.0 and 23.1a1 on our code base, most of it looks really good โค๏ธ as always thanks for the great work
however there is one pattern of change that doesn't seem ideal, it's possible this has been flagged already, I wasn't sure what to look for.
22.8.0
common.models.DateTimeField: (
datetime(2020, 1, 31, tzinfo=utc) + timedelta(days=i)
),
23.1a1
...
The latest docker release on docker hub is pointing to an alpha version. I would have expected latest_release to be the latest release, and not the very latest on git.
Is there a way to fix this to go back to 22.12.0?
I've just tested this out with a medium-sized codebase. All as expected apart from this one issue with a comment at the end of a function getting 2 newlines added above it. Removing @decorator1 stops the comment getting moved, as does removing # fmt:skip.
^^ This is not desirable I guess ...
yes
Trying to log in now and see if I can delete
Just on work Linux box now and it's logged into nothing
Looks like I'll need my personal laptop to move the tag
Web only lets me delete
Ok - reran the aciton. Seem to do what we needed.
Later today I'll try find some time to see if we can fix this for draft released and don't move the latest_relrese tag etc.
0>, 'Connection to pypi.org timed out. (connect timeout=15)')': /simple/hatchling/
ERROR: Could not find a version that satisfies the requirement hatchling>=1.8.0 (from versions: none)
ERROR: No matching distribution found for hatchling>=1.8.0
Must be setuptools not liking proxy
Trying to run the alpha over FB code now
Is there a direct way I can call hatch to build black? Seems setuptools using hatch in a proxy server environment is unhappy and I can get debug pip output to tell me what ti's trying to do exactly. I could strace I guess
PEP 701 is going to make our lives difficult unless Batuhan can unleash some more magic
!pep 701
๐ฎ
Least he is all over the PEP
Will look at some formatting changes soon
I don't even know how to checkout instagram anymore. Been so long
Gonna post and ask other pythonistas to help test in a bit
only 400k lines?
This is only sub sections of the repo
My dev box will run out of disk if I pull everything
Will try clean it up this afternoon and let it run on more of the repo overnight
thanks!
Might even try remember how to checkout instagram
The removal of the newline for context managers + function/class definitions going to make a lot of change in our code
That's main change I see
<!--
Please make sure that the bug is not already fixed either in newer versions or the
current development version. To confirm this, you have three options:
- Update Black's version if a newer release exists:
pip install -U black - Use the online formatter at , which will use
the latest main branch. - Or run Black on your machine:
- create a new virtualenv (make sure it's the same Python version);
- clone this repository;
- run
pip install -e .[d]; - run `...
Is your feature request related to a problem? Please describe.
I am working in a Databricks environment and developing workflows there. Unfortunately, it awkwardly requires external dependencies to be installed in the running file in order to make them available. Sample shown below. The issue here is that in development when trying to use black to format the file black will fail with Cannot parse: 4:0: %pip install my_lib. This means the whole file can't be formatted.
Sweet - Found what was eating all my space - Will kick it off over the whole repo
<!--
Please make sure that the bug is not already fixed either in newer versions or the
current development version. To confirm this, you have three options:
- Update Black's version if a newer release exists:
pip install -U black - Use the online formatter at , which will use
the latest main branch. - Or run Black on your machine:
- create a new virtualenv (make sure it's the same Python version);
- clone this repository;
- run
pip install -e .[d]; - run `...
current analytics for the new blog post
<!--
Please make sure that the bug is not already fixed either in newer versions or the
current development version. To confirm this, you have three options:
- Update Black's version if a newer release exists:
pip install -U black - Use the online formatter at , which will use
the latest main branch. - Or run Black on your machine:
- create a new virtualenv (make sure it's the same Python version);
- clone this repository;
- run
pip install -e .[d]; - run `...
We need to get these numbers up, so I'm going to post about 23.1a1 to ...
- #python-community
- PyPA Discord
- r/Python
- maybe https://discuss.python.org/?
Yeah, why not discuss.python.org - Can't hurt
It might be worth it pinging some major projects using Black too (looking at the diff-shades project list would do)
<!--
Please make sure that the bug is not already fixed either in newer versions or the
current development version. To confirm this, you have three options:
- Update Black's version if a newer release exists:
pip install -U black - Use the online formatter at , which will use
the latest main branch. - Or run Black on your machine:
- create a new virtualenv (make sure it's the same Python version);
- clone this repository;
- run
pip install -e .[d]; - run `...
Unless someone wants to become responsible for stabilizing ESP, I agree with Jelle it should be trimmed down or removed entirely.
There really are a ton of lingering issues w/ ESP
I want to stabilize ESP (that's why I'm filing all those bugs after running it over our codebase ๐ )
I don't want it in the 2023 preview style unless we can actually stabilize it
Otherwise people can't use --preview to see what the next stable style will actually look like
that would be great!
I meant stabilizing as in eventually, but currently it will never become stable.
Oh I misread you Jelle, I totally agree
We have enabled it on 1/5 of our code for a few weeks now (we use incremental formatting via the https://github.com/google/pyink fork so it's only formatting changed code while people making changes), but the feedbacks are overall positive
!voiceverify
You should run this command in #voice-verification , not here :)
<!--
Please make sure that the bug is not already fixed either in newer versions or the
current development version. To confirm this, you have three options:
- Update Black's version if a newer release exists:
pip install -U black - Use the online formatter at , which will use
the latest main branch. - Or run Black on your machine:
- create a new virtualenv (make sure it's the same Python version);
- clone this repository;
- run
pip install -e .[d]; - run `...
- When we do a pre-release lets not move the latest_release tag
- This tag should only move on official real releases
Fixes #3453
Would love any ideas on how to test this ...
Other than psf/black#3368 and the ones I already covered, what other changes haven't been promoted?
I'd guess psf/black#3440 is another one
everything that didn't make it into 22.12, so whatever is in main's CHANGES.md
Perfect. I want to fix my blog post before I promote it more widely
and ESP obviously
I don't understand the GitHub Webhooks documentation at all, but this looks about right.
hmm, did psf/black#3430 make it into the 2023 stable style? It appears it has looking at at the 23.1a1 source code
yes, that one did
but it's a fixup for an earlier preview change
yup, just was curious as it's under main's changelog
oh and psf/black#3368 also did not make it into the stable style
@dense jungle can you see my draft announcement here? #python-community message
yes
If so I would like a quick readover and then I'll click publish
looks good. didn't realize it was a draft ๐
Thanks!
Not really sure if there's a category in discuss.python.org that's appropriate. The Python Help category is the best, but still isn't great.
I'll make a post on r/Python though.
Description
This PR excludes string type annotations from ESP, and also fixes crash on mismatched brackets from ESP.
- Unfortunately pyright doesn't support stringified annotations that span multiple lines, e.g.:
def something(
arg,
) -> (
"VeryLongClassNameWithAwkwardGenericSubtype[int] |"
"VeryLongClassNameWithAwkwardGenericSubtype[str]"
):
...
Even though other type checkers (mypy, pytype, pyre) do support them. To be safe, we can ch...
Description
Fixes #3459.
Checklist - did you ...
- [x] Add an entry in
CHANGES.mdif necessary? - [x] Add / update tests if necessary?
- [x] Add new / update outdated documentation?
Black v23.1a1
Options
--line-length=88
--safe
Input
x = [
1,
2,
3,
]
Output
x = [
1,
2,
3,
]
Expected
x = [1, 2, 3]
Desc...
Description
Over here, https://github.com/psf/black/issues/3453#issuecomment-1357988758 while fixing an issue with the Docker image publishing workflow, it seemed there's a legitimate desire for a docker tag which follows alpha (prerelease) releases of Black. This PR creates a new tag to be pushed to Docker Hub going forward (latest_prerelease which will be updated with every alpha version release.
I do have another change to request along with this...
If someone comes acro...
Awesome. Thanks. LGTM - Will leave it a day or two to give other maintainers a chance to voice any thoughts etc.
We don't do pre-relaases that often.
I got a lot of our code ran - with very few errors. I just need to load the config file with the directories to ignore - Will try get to that next few days
My internal post asking people to try hasn't rendered much action either
https://discuss.python.org/t/pep-701-syntactic-formalization-of-f-strings/22046/24 is worth voting on. :)
As I assume this is going to be a controversial point of the proposal I am making a poll. Question: Do you think that f-strings should allow quote reuse within the expression part? (as in fโ something { my_dict[โkeyโ] } something else โ) poll Please take the time to read the PEP first and then the discussion so far regarding sone of the argume...
I like but I feel it's going to make parsing harder for us ...
Bring it up on that thread ๐ค
I get very low success on these threads. Feels like a void for me, so I stopped going.
I don't think it can hurt to do that (unless it's already come up)
Hehe, okie. Well, I'll just leave it at that then... ๐
is this the pep that makes f-strings a parser-level thing, and thus infinitely nesting strings is allowed?
In other news, I'm here to say that I am excited about the formatting changes coming in next year!
I'm especially keen to see how the theoretical "good stability policy" is going to work out in practice. ๐
Yes.
I personally prefer lots of smaller changes (thus I run --preview), so the stable policy while I get it, I find overhead and just prolonging tech debt
right. as someone implementing a python parser, i actually figured this would make my job easier, given that i can just parse it as yet another expression node and make the lexer more general (less nesting special-casing). why does it make parsing more complicated for black? (i really need to look into how it works right now >.>)
We just force larger blanket formatting diffs at the start of each year now
Describe the bug
With preview style, a long f-string where the only spaces are in the expression bit has parentheses added even though it isn't split over lines. For example:
f(
f'longstringwithnospacesinthestringbitbutwithspacesintheformattyfstringbithere{ 1 }',
)
becomes
f(
(
f"longstringwithnospacesinthestringbitbutwithspacesintheformattyfstringbithere{ 1 }"
),
)
I would instead expect it not to have changed. [See on black ...
Description
Previously, when ESP 1) merges strings in StringMerger; 2) strips parens in StringParenStripper, it finds and does one transform for one string group. Each transform will create a new line with 1) one group of strings merged; 2) one group of strings' parens stripped. This new line is then re-checked by those transformers. This is O(n^2) complexity.
Since these transformers won't cause line breaks, the same transforms can be done at one pass, and it only cre...
Thanks, this is an exciting improvement! I'll need to study the code some more and see how it affects perf on my codebase where I previously saw terrible performance.
Description
This is a few documentation changes for the Vim plugin. I included them in the same PR to avoid clutter and because they're all pretty minor and easily reviewed together. I also made a commit for each thematic change, so feel free to look at specific commits if you want to see the changes in isolation. I didn't think this was a substantial enough change to warrant a CHANGES.md entry, but am happy to add one if maintainers disagree.
There are 4 main changes in here:
...
a44dc3d Exclude string type annotations from ESP (#3462) - yilei
I forgot to mark my review as "request changes" which is relevant since this PR can still crash.
So much action !
Description
Fixes #3455.
The resulted formatting is the same as current stable, and making the result nicer is out of ESP's scope.
Checklist - did you ...
- [x] Add an entry in
CHANGES.mdif necessary? - [x] Add / update tests if necessary?
- [x] Add new / update outdated documentation?
73c2d55 Fix a crash in ESP where a standalone comment i... - yilei
59f03d1 Vim plugin docs improvements (#3468) - matthewarmand
Description
Fixes #3454.
This is actually unrelated to # fmt: skip, as this also happens when a regular standalone comment is placed between decorators.
This is a regression caused by https://github.com/psf/black/pull/3302 (Preview.empty_lines_before_class_or_def_with_leading_comments)
Checklist - did you ...
- [x] Add an entry in
CHANGES.mdif necessary? - [x] Add / update tests if necessary?
- [x] Add new / update outdated documentation?
Is your feature request related to a problem? Please describe.
Currently if the class inheritance ends with a comma the list is not collapsed if it takes less place.
Describe the solution you'd like
I would like black to check whether the list of inheritance classes fits on a single line.
lol, that was an unexpected ping
https://twitter.com/ossinsight_bot/status/1606208048913317893
Congrats to psf/black, which has grown by 158 stars in the last 7 days and has reached 30.6K stars.
Thanks to the contributors: @sichard26 @cooperlees @hugovk @llanga @JakubKuczys
https://t.co/IQhFE4tbUM
#Python
Unsure why it even chose me
Is it just iterating through users until it finds 5 Twitter handle? Because I'm rather far down in the contributor list
Thanks! Functionality and test wise this all seems good to me. There is some deep code in lines.py that I don't get so would want one of the AST smart maintainers to be happy with before final merge.
Tears apart bandersnatch test formatting
I'm torn on the """ brought up to the first ( now looking at it ...
Sorta goes against other ways we format
Regarding
, if quotes reuse stays in the PEP, I think that Black should use single and double quotes alternately when formatting arbitrarily nested f-strings to make it easier to differ between next levels of nesting, i.e. ```py
before
f"{f"{f"infinite"}"}" + " " + f"{f"nesting!!!"}"
after
f"{f'{f"infinite"}'}" + " " + f"{f'nesting!!!'}"
I don't think there's an issue for PEP 701 yet since it's still a draft so just putting my opinion out there
I guess that if someone used """ on the outside f-string then I would expect formatting to be like this:
f"""
{f"{f'{f"{f'infinite'}"}'}"}
"""
This crashes in 23.1a1:
async def f():
with (x := await sleep(0)):
pass
Reported by @Zac-HD in https://github.com/psf/black/issues/3407#issuecomment-1364681511.
another similar one ```% black --preview -c 'for (x := 3, y := 4) in y: pass'
for (x := 3, y := 4) in y: pass
error: cannot format <string>: Cannot parse: 1:6: for x := 3, y := 4 in y:
>>> for (x := 3, y := 4) in y: pass
File "<stdin>", line 1
for (x := 3, y := 4) in y: pass
^^^^^^
SyntaxError: cannot assign to named expression
it is not valid syntax
yes, but we have a bunch of similar test cases already to appease fuzzers (tests/data/fast/pep_572_do_not_remove_parens.py)
Description
Fixed typos:
everyting -> everything
reponse -> reponse
Checklist - did you ...
- [ ] Add an entry in
CHANGES.mdif necessary? - [ ] Add / update tests if necessary?
- [ ] Add new / update outdated documentation?
They changed reponse to reponse ๐
Merry Christmas!
I'll review your PR from today. I have it open, but I've been distracted fiddling with C :)
no hurry!
Okay time to stop fiddling with C. I split my codebase into several files and now I'm figuring out how I can get Make to automatically set up prerequisites so changes to header files don't require a clean rebuild... an initial read of the Make docs is flying over my head ๐ฅด
"S" in "C" stand for "sanity" lol
Looks good, but I'd double check the test data file. I don't think it's testing what you want.
https://github.com/psf/black/pull/3415 I'm just looking at the PRs merged during my absence... how do you even review something like this?
Later on, I might take a look at some of the major PRs merged during my absence, but I'm not worried about the smaller bugfixes (they look pretty good on a surface read). I did spot a changelog error though :)
https://github.com/psf/black/blob/72a3408965f944f39f1080a5b67c25790acdc4e2/CHANGES.md?plain=1#L23-L26 "advanced string processing"
CHANGES.md?plain=1 lines 23 to 26
- Fix a crash in preview advanced string processing where mixed implicitly concatenated
regular and f-strings start with an empty span (#3463)
- Fix a crash in preview advanced string processing where a standalone comment is placed
before a dict's value (#3469)```
no
Currently investigating hatch w/ mypyc, seems like the situation got even worse?
oh no, what's wrong?
You mentioned that even the x86_64 wheels didn't work: https://github.com/psf/black/actions/runs/3658832698/jobs/6184104544. It turns out macosx_11_0_x86_64 is not a valid platform tag for Python 3.7
It can be at most 10_9 AFAICT, but I have no idea why 11_0 is being selected in the first place.
I don't trust any of the platform tags generated by hatchling to be honest
I might do a test build switching back to setuptools and figure out what the platform tags should actually be for macOS.
... Are you waiting for me to review? I can do that later tonight
I'm surprised you didn't merge that right after approving it
I got distracted, do you want me to wait?
sure, I can take a look after I figure out what's wrong w/ hatch
(battling wifi issues on my main machine right now though, ugh)
Honestly it might be easier to just revert the hatchling PR instead of dealing with this mess
sad but that might be the right call
I might merge psf/black#2278 if I like what diff-shades has to say
wow may 2021
I started at the oldest open PRs lol
I'm not concerned about the implementation at all so as long as you like the diff-shades results, feel free to merge
it's really simple actually
https://github.com/psf/black/blob/2fecc15a6fb8f6af444af2c1d4132f9943092f3b/src/black/linegen.py#L152-L153 I'm surprised this doesn't cause any problems though
src/black/linegen.py lines 152 to 153
lpar = Leaf(token.LPAR, "")
rpar = Leaf(token.RPAR, "")```
invisible parentheses?
yea, although I don't know well enough how we treat them to know whether it'd be a problem
one thing about setuptools is that editable installs might require some tweaking since they massively changed how they work
reverting doesn't look too hard, but keeping the 3.6 removal changes will be a pain
nevermind, there are 5 conflicts!
OK so patched hatchling seemed to fix the ARM64 build, but the universal2 and more importantly the x86_64 builds are still broken.
hal
Turns out packaging is implicated in this: <#964878415914213436 message>
The TL;DR is that packaging 22.0 changed how tags for Python 3.7 (and maybe 3.8?) on macOS are determined and that's causing hatchling to build wheels with platform tags pip can't install. macosx_10_16 is effectively equivalent to macosx_11_0 but pip doesn't know that since it vendors packaging 21.something.
Now I have no idea whether hatchling is producing the ideal platform tags, but if we use hatchling from main with packaging 21.3, the build works. https://github.com/ichard26/black-mypyc-wheels/actions/runs/3804407857/jobs/6471680692
Ofek is planning a new release of hatchling that bans packaging 22.0 so in theory we should be able to provide mypyc wheels for macOS soon.
This kind of issues makes me wonder why modules like packaging are not part of stdlib
Description
Let's skip the check if we're running on a fork just in case someone opens a PR against a branch on said fork as part of a PR review upstream.
Example run: https://github.com/ichard26/black/pull/60
Checklist - did you ...
- [x] Add an entry in
CHANGES.mdif necessary? -> n/a - [x] Add / update tests if necessary? -> n/a
- [x] Add new / update outdated documentation? -> n/a
can't believe @bright glacier hates CI ... Image managing black without it !
I don't actually, but writing it can be a real pain my gosh
me: writes draft
gha: red all over
me: pushes a hotfix
gha: no.
me: pushes another hotfix:
gha: no.
[repeat 10 more times at least]
gha: you've proven yourself worthy, it shall work now
You have no idea how much time I've spent debugging hatch-mypyc. Probably north of 3-4 hours now. The #hatch channel on PyPA has been busy these past two days ๐
I still don't know what the proper fix is to be honest.
I need to learn how to SSH into a GHA runner, will finally give me access to a macOS machine. (or I could apply for access to the GCC compiler farm for once)
I can link you ngrok example
Hugovk already sent me a link on how to, I haven't tried yet (need to learn how to use SSH first)
Btw, if you need an M1 test machine, Cirrus CI actually has a more native ssh feature, can just use the shell from the web ui
I feel you with long debugs โฆ Iโve spent weeks on things at work โฆ (on and off of course)
hi
Description
I have a public OSS email address now!
Checklist - did you ...
- [x] Add an entry in
CHANGES.mdif necessary? -> n/a - [x] Add / update tests if necessary? -> n/a
- [x] Add new / update outdated documentation?
Thank you! I appreciate all of your in-depth investigation, I don't understand what's wrong here myself, but this seems safe have read your comments.
I'll reach out to the click folks tomorrow, but I agree it's very possible click won't fix this for us as it (seems to) requires monkeypatching the standard streams.
Sorry for taking so long to get back to you!
Is your feature request related to a problem? Please describe.
When using black to format long lists of files, one must use a tool like xargs to avoid triggering the platform's maximum command-line length. For example, if I want to clean up the modified files in my workspace, I can't write this:
black $(git status --porcelain | cut -c3- | grep -e '*.py$')
Because the command-line would overflow. Instead, I have to write it this way, triggering black multiple times:
`...
interesting...
pre-commit solves this issue nicely, since it only passes modified files to the hook
but what if you modify so many files that it exceeds the argv length limit ๐
support reading a file with paths separated by newlines /j
I haven't read the issue, but I wouldn't be surprised if that's the suggestion haha
I would say that this is quite a rare case to go over the args limit
the mypyc command line errors out due to a new setuptools feature, great.
Please consider adopting https://github.com/ossf/scorecard in your project CI.
TL;DR - It scans CI configs for token permission overreach security issues and looks at transitive deps with issues to surface potential problems. (running it will give you a better idea than I can list off the top of my head)
Hi folks!
Does black's CI and package publishing depend on CircleCI or is it impacted by the recent breach0 to their infrastructure?
no, never used circleci
@dense jungle Thank you! โค๏ธ It may help to put out a statement with so folks trying to ensure they aren't hit with a supply chain attack after this breach.
But I appreciate the response very much
I notice there aren't many dependencies black depends on much either. ๐
not using the issue report format since it doesnt really fit here
originally, i was having an issue that looked like this:
> black
Traceback (most recent call last):
File "/home/zero/.local/bin/black", line 8, in
sys.exit(patched_main())
File "src/black/__init__.py", line 1481, in patched_main
KeyError: 'maybe_install_uvloop
i then updated through python3 -m pip install -U black.
now, instead when i run black (both through black and python3 -m black), i...
Can someone point me in the direction? I'm wanting to enforce black on all python code across all our repos. My understanding is that I can do that on a repo-by-repo basis by using GitHub actions as described here. So I added the .github/workflows/black.yml file to a repo and did both a pull and a push and, while nothing broke (great!), I don't know that ANYTHING happened (not so good). It was my expectation that either the file I changed would be run through black or ALL the files in the repo would be run through black.
Either of those options would be great. TIA
(p.s. anyone else miss decentralized mail-list communities that had searchable archives? just me?)
you know you can search on discord ๐ค
I don't know that ANYTHING happened (not so good).
if you go to the Actions tab at the top of the repo, and click the run, do you see the workflow?
i've never once had a google hit pointing me at discord.
bad search, and it's not publicly archivable
Ah - thanks. Something did indeed happen. The Run psf/black@stable line failed with exit code 1. Looks like I'm trying to do too much at once?
well, that action won't actually reformat your code
by default, it will simply check and than fail CI if the code isn't properly formatted
otherwise the github actions bot would have to commit to your code
OK - thanks. I misunderstood the outcome.
I'm open to add a feature (locked behind an option) to the action that automatically pushes changes, but you could just use pre-commit.ci OTOH. Feel free to open a feature request if there isn't one already.
Also, while working on python/mypy#14409 I was looking for some evidence people do actually loop over set literals. I didn't expect I'd find an example from Black :D
I want to install หblack[d]ห in Windows 11 64 bit.
pip install 'black[d]'
...
building 'yarl._quoting_c' extension
error: --plat-name must be one of ('win32', 'win-amd64', 'win-arm32', 'win-arm64')
[end of output]
note: This error originates from a subprocess, and is likely not a problem with pip.
ERROR: Failed building wheel for yarl
Failed to build aiohttp frozenlist multidict yarl
ERROR: Could not build wheels for aiohttp, frozenlist, multidict, ...
Describe the style change
Consider this example
with g5.ExtendableList(output, "r", np.uint64) as dset_r,\
g5.ExtendableList(output, "t", np.float64) as dset_t,\
g5.ExtendableList(output, "dx", np.float64) as dset_dx,\
g5.ExtendableList(output, "ds", np.int64) as dset_ds:
Examples in the current Black style
with g5.ExtendableList(output, "r", np.uint64) as dset_r, g5.ExtendableList(
...
Still exploring options. Features and drawbacks to any approach. I like the idea of a filter that automatically and arbitrarily formats everything without developers being able to, or having to, do anything about it. "Code as law" effect. Afraid if I enforce them running black on their own then we have to argue about who's settings are most correct. Plus overhead of one more tool to install.
Reference to "Code as (sic) law" -- https://journals.openedition.org/factsreports/4518#:~:text=As stated by Lessig (1999,individual's%20actions%20via%20technological%20means.
I wouldn't say the extra tool overhead is that much. And as to configs, you set a standard in your project and everyone just uses it, no arguing
Although when the target version is Python 3.9 or higher, Black will use parentheses instead since theyโre allowed in Python 3.9 and higher.
This doesn't look like implemented? https://black.vercel.app/?version=main&state=_Td6WFoAAATm1rRGAgAhARYAAAB0L-Wj4AFLAKddAD2IimZxl1N_WmufDs0LojAMwSd5y6tVHFECi48em1NmrZSWd-aOQDsyxUoj0wG4N0KjynelfrUIzSWL64h5VoX_mCOwgMPUKBe_kpQGb8ToKkTNJMhtPCsqZ-aszOI5WcjMdmBg-q7cPX3coevA_OIpFObLOmoS5kucg6QUzHvL6k7_9RcyS-tVYfqVbx0JL_U2lXGCnRBPkIbvpyjV8-xUtCGeqEUAAAA8zdsAm2iELQABwwHMAgAApxRWVrHEZ_sCAAAAAARZWg==
Playground for Black, the uncompromising Python code formatter.
yes, I don't think we actually implemented that
maybe "will use" there is supposed to mean "will, when we implement this, use"
but it would be good to make that explicit
and even better to actually implement the behavior as described ๐
I'll take a look at it then. Also this should be 3.10+ since it's only officially allowed in 3.10
So that we actually implement https://black.readthedocs.io/en/stable/the_black_code_style/future_style.html#using-backslashes-for-with-statements:
Although when the target version is Python 3.9 or higher, Black will use parentheses instead since theyโre allowed in Python 3.9 and higher.
I'll work on a PR to implement this when targeting Python 3.10+ (since it's only officially allowed in 3.10 https://docs.python.org/3/whatsnew/3.10.html#parenthesized-context-managers, though accidenta...
We talked about this before. It works in practice in 3.9 and that's not going to change, so it seems reasonable to format that way for 3.9+
except when you use PYTHONOLDPARSER=1 ๐ but yeah it will be fine in practice so this SG
and I don't think it was quite "accidental" as you put it in the issue, it's more like Guido and co snuck it in ๐
Describe the bug
Take this code:
import re
match = re.match(r"(?PLD|MD|HD)(?PAL|SS)", "HDSS")
match (match.group("grade"), match.group("material")):
case ("MD" | "HD", "SS" as code):
print("You will get here")
And run it with these arguments:
$ black file.py --target-version py310 # or --target-version py311
The resulting error is:
cannot format foo.py: Cannot parse: 3:0: match (match.group("grade"), match.group("material")):...
The backslash & paren-wrapping formatting for multiple context managers aren't yet implemented.
Related to #3486.
Description
Fixes #3486.
This also fixes the target version detection logic for parenthesized context managers (3.9) and match statements (3.10). But as far as I can tell, this didn't have user visible impact (until this PR).
I added a dedicated test data folder preview_context_managers, because this relies on the version detection logic when --target-version is not explicitly specified.
Checklist - did you ...
- [x] Add an entry in
CHANGES.mdif neces...
Always have a blank line between class declaration and first inner method.
How I would like the code to look after black formatting:
class BaseAPIClient:
def __init__(
self,
session: ClientSession,
) -> None:
self._session = session
Code after black current formatting:
class BaseAPIClient:
def __init__(
self,
session: ClientSession,
) -> None:
self._session = session
PEP8...
I am porting a new project to black and wanted to consult on the options available, however I cannot find the full list of options in the documentation.
In Usage and Configuration, it states:
Youโve probably noted that not all of the options you can pass to Black have been covered. Donโt worry, the rest will be covered in a later section.
However I cannot find a section describing all optio...
The CLI options were already shown in the "Command line options" in the same page.
Close #3491
"""This is a module docstring.
"""
def func():
"""This is a func docstring.
"""
is formatted to:
"""This is a module docst...
Describe the style change
Star unpacking containers in combination with modifying the container with an operator has a somewhat unintuitive operation ordering, and I think should probably have enforced parentheses.
Examples in the current Black style
def foo(other_var: Any):
my_set: set[str] = {"a", "b", "c"}
my_list: list[int] = [0, 1]
print("hello", *my_set | {d}, "world")
bar(*my_list + [2])
# TypeError if other_var is not a set,...
Is one able to manage the way that black formats imports? Without the wrapping and having an import on each line instead
Black doesn't change imports, other than line wrapping. Use isort
Describe the bug
I already reported this on the isort side in case it belongs there: https://github.com/PyCQA/isort/issues/2070
I ran black and isort --profile=black against a file and they both format the file differently
To Reproduce
Python example code:
from google.api_core.exceptions import AlreadyExists, BadRequest, ClientError, Conflict, NotFound
Run black against that file like this (Note: I have no config files for black or isort in this min...
Sorry for the late review. The content does look good, although Prettier needs to be satisfied. In any case, thanks for re-introducing this! ๐
Describe the bug
Black is encountering an INTERNAL ERROR when a type hinted comment has a trailing space.
To Reproduce
For example, take this code:
With the trailing space after # type: dict[str, str] black encounters an internal error
d = {} # type: dict[str, str]
remove the white space character like type: dict[str, str] and the file is formatted.
And run it with these arguments:
$ black t.py
error: cannot format t1.py: INTERNAL...
Describe the bug
From #2188: When processing a multiline string in a function argument default value with --preview (ESP), it is concatenated even if it will exceed line length.
To Reproduce
Here's a [playground link](https://black.vercel.app/?version=main&state=_Td6WFoAAATm1rRGAgAhARYAAAB0L-Wj4AIZAPddAD2IimZxl1N_WlbvK5V-4XXUGvpeVcLH8iKYR8mKJ8OeVa2yGQN68ELSum2f5bZ5aTWDTpb6tVSmXkCas7K79A96W2lU3uDWQBaoO8HRG7ct00CbiHOlm1rvQ9QNG_jvTC3cqe3ZdMUVm3DNf9kK-7kHuH1ImqdVbOHxBxgAGrz2ShWgzM0...
Hi! Thanks for the work and sorry for the late review on my part as well. A couple of small comments and a gentle wish below if you still have energy for this PR ๐
I'd adore it if you could explain the algorithm a bit perhaps in a comment, or even try to break it into more bite-sized pieces so that the big picture is clearer. Like finding the leaves that are inside the line (L783-L788). Took me a solid hour to start to understand, particularly the manipulation of max_level_to_update ๐ (a...
!src
Thank you! Sorry for taking so long to land this.
Sorry for the late review. The content does look good, although Prettier needs to be satisfied. In any case, thanks for re-introducing this! ๐
d4ff985 Add IntelliJ docs on external tools and file wa... - ruslaniv
@dense jungle in the issue linked in psf/black#3473 you mentioned that this PR doesn't fix all the similar cases. Should we keep that issue (psf/black#3472) open?
Otherwise, I'm going to merge your PR.
hm I'll have to check, maybe I ended up fixing those too?
Describe the bug
I my python file a line with more than 80 characters exists but black doesn't split the line into multi lines due the line length constraint.
To Reproduce
the is my "test.py" file
graph_path_expressions_in_local_constraint_refinements = [
graph_path_expression
for refined_constraint in self._local_constraint_refinements.values()
if refined_constraint is not None
for graph_path_expression in refined_constraint.condition_as_predicate.variable...
Thank you for addressing the comments, and sorry for the late re-review! This is looking good to me ๐
Logic seems sane when we add what space to set the bool + use. Tests are good and make sense.
Will leave it to you to rebase or I can to merge?
Description
The option is max-line-length with dashes, not underscores. The config option name is given in the output of pycodestyle -h, which can also be checked on https://pep8.readthedocs.io/en/stable/intro.html#example-usage-and-output:
Configuration:
The project options are read from the [pycodestyle] section of the
tox.ini file or the setup.cfg file located in any parent folder of the
path(s) being processed. Allowed options are: exclude, filename,
...
It seems that black indiscriminently prints emojis. Could you PLEASE give us an option to disable unicode output, just like we can disable color output? Not everyone is able to or chooses to use unicode-capable terminals, and these multi-byte characters will screw up many terminals, as they can be interpreted as terminal control codes or expected to render as single characters per byte.
since plugins are unbound, new issues raised. should I fix them within my PR or open another PR fixing those?
I took it upon myself to "fix" #3501 (emojis)
we may want to just disable that check (I have done that on a few other projects). Haven't looked at the cases in Black where it triggers though
it's just f'"{value}"' -> f"{value!r}" everywhere
hm !r gives single quotes so that's not necessarily safe
depending on what we need the quotes for
from what I can see, it's mostly output messages formatting
I think some terminals treat " in output differently so that might have been on purpose
so, should I add this error code to ignores?
Description
Resolves: #3501
This PR adds a CLI option to disable emojis in output messages.
Checklist - did you ...
- [x] Add an entry in
CHANGES.mdif necessary? - [ ] Add / update tests if necessary?
(Didn't find any tests for the output, but can add them if necessary) - [ ] Add new / update outdated documentation?
(Could use some directions as to where to put the update about new CLI option)
oh good, thanks for linking that
Though it seems you use ignore instead of extend-ignore in the .flake8 so you'd need to disable it anyway (or change that)
You can "fix" diff_shades_gha_helper.py but IMHO this check is a bit overzealous.
I am going to add ignore in another PR, as Jelle suggested in review
Description
This adds newly introduced flake8-bugbear B028 rule to ignore list
Checklist - did you ...
- [ ] Add an entry in
CHANGES.mdif necessary? - [ ] Add / update tests if necessary?
- [ ] Add new / update outdated documentation?
None of those are necessary here.
fyi @ivory quest it's generally frowned upon to force-push PR branches, since it makes it harder for reviewers to see the history. Just push a new commit, and when we merge we'll squash them together
(not sure if this workflow preference is true for all repos)
sorry, habit
not a big deal but something to keep in mind
will remember ๐
ah CI is broken because of bugbear, that's great
I was wondering why the PR I was reviewing is red :D
fix is spinning on CI
fix is ready to be merged btw
thanks for your contribution!
Describe the style change
I've repeatedly messed this up as of late, and only afterwards realized I've been horribly inconsistent on where I place the spaces in multi-line strings.
Examples in the current Black style
Black will currently not reformat either of these multi-line strings
my_string_1 = (
"words that are in the first line "
"words that are in the second line "
"words that are in the third line."
)
my_string_2 = (
"words that are i...
<!--
Please make sure that the bug is not already fixed either in newer versions or the
current development version. To confirm this, you have three options:
- Update Black's version if a newer release exists:
pip install -U black - Use the online formatter at , which will use
the latest main branch. - Or run Black on your machine:
- create a new virtualenv (make sure it's the same Python version);
- clone this repository;
- run
pip install -e .[d]; - run `...
This looks good. I'm so sorry for dropping the ball on this!
We should fix and overhaul the file collection and discovery tests, it's not great that it's not testing typical usage. Could you open an issue? It's okay if you don't want to.
Thank you very much!
18fb884 Fix false symlink detection claims in verbose o... - aaossa
Yay I did something for once.
!remind 18H review that infer target-version PR you've been meaning to for like 2 months >.<
Your reminder will arrive on <t:1674161252:F>!
thanks @errant barn for doing a review in the meanwhile
Here's your reminder: review that infer target-version PR you've been meaning to for like 2 months >.<
[Jump back to when you created the reminder](#black-formatter message)
yes, or 23.1 --preview
<!--
Please make sure that the bug is not already fixed either in newer versions or the
current development version. To confirm this, you have three options:
- Update Black's version if a newer release exists:
pip install -U black - Use the online formatter at , which will use
the latest main branch. - Or run Black on your machine:
- create a new virtualenv (make sure it's the same Python version);
- clone this repository;
- run
pip install -e .[d]; - run `...
Description
See 'How to fix` in #3507
Checklist - did you ...
- [X] Add an entry in
CHANGES.mdif necessary - [X] Add / update tests if necessary?
- [X] Add new / update outdated documentation?
Description
Fixes #3506
We can't simply escape the quotes in a naked f-string when merging string groups, because backslashes are invalid.
The quotes in f-string expressions should be toggled (this is safe since quotes can't be reused).
Checklist - did you ...
- [x] Add an entry in
CHANGES.mdif necessary? - [x] Add / update tests if necessary?
- [x] Add new / update outdated documentation?
Describe the style change
#3440 (closing #620 and #808) improved handling of long expressions in dict values by putting them in parentheses, but the same values in arguments aren't always handled nicely.
Examples in the current Black style
dict(
key_key_key_key=a_long_long_long_long_long
* b_long_long_long_long_long
/ 100.0
)
dict(
key_key_key_key_key_key_key_key_key=lambda: some_very_long_function_name(
x, y, z
)
)
...
Hatchling implemented a workaround for the 'technically right tag but no one understands it, including pip' issue so this should work now.
https://github.com/ichard26/black-mypyc-wheels/actions/runs/3971519300
Don't click links
Avoid clicking on any link,
What are you waiting for, my account is not safe so neglect any massage or task or change for now. Thank you all for understanding and cooperation, do not accept any changes so work with our first agreement
Work with the first instructions when created
Work with the first instructions because Olumeni1 projects has been stolen by brothers and partners working with him
Any ideas call me on 09019760402 or my Gmail wisdomolumeni32@gmail.com
I pr...
Description
Same commit as in PR #3500 but made new PR targeting main.
The option is max-line-length with dashes, not underscores. The config option name is given in the output of pycodestyle -h, which can also be checked on https://pep8.readthedocs.io/en/stable/intro.html#example-usage-and-output:
Configuration:
The project options are read from the [pycodestyle] section of the
tox.ini file or the setup.cfg file located in any parent folder of the
path(s) bein...
heh why did I not close that. I opened this issue when I got up, but I never closed it ๐
you were just being careful as the issue asked for
sometimes I just don't understand github spam: https://github.com/pi-apps/pi-platform-docs/pull/255
<!--
Please make sure that the bug is not already fixed either in newer versions or the
current development version. To confirm this, you have three options:
- Update Black's version if a newer release exists:
pip install -U black - Use the online formatter at , which will use
the latest main branch. - Or run Black on your machine:
- create a new virtualenv (make sure it's the same Python version);
- clone this repository;
- run
pip install -e .[d]; - run `...
Description
This small change is to fix the issue #3515. It adds a sorted(...) to the PYTHON_CELL_MAGICS set wrapped inside a string.join() in order to have a stable output in the black --help command. No other changes are required.
Checklist - did you ...
- [ ] Add an entry in
CHANGES.mdif necessary? See comment below. - [ ] Add / update tests if necessary? : Did not find something that checks the existing output
- [ ] Add new / update outdated documentati...
wow that repo is a spam disaster
it really is, shame that it seems to be getting worse slowly over time :(
while I have your attention, would you mind looking at https://github.com/mypyc/mypyc/issues/849?
that seems worth doing! if you send a PR to the wheel builds repo, I will review and see it through
Is this related to a problem? Please describe.
Describe the solution you'd like
Describe alternatives you've considered
Additional context
eabff67 Format hex code in unicode escape sequences in ... - Shivansh-007
a36878e Fix an invalid quote escaping bug in f-string e... - yilei
Is your feature request related to a problem? Please describe.
This has a design goal to solve the problem addressed in #1281, #2026, #3182: formatting of very large arrays, but in a different way than proposed.
Describe the solution you'd like
Those two issues were closed because black does not want to introduce an external argument to determine array formatting. That makes complete sense, as adding an argument would lead to fragmenting style.
Instead, I would like to s...
does black format code using \ to split long lines?
Nope
There were plans to split with on <3.9 using \
I somewhat doubt anyone will want to pursue it anymore considering that 3.8 will be EOL in ~a year
There's also """\ which doesn't happen automatically but isn't removed by Black
though there are plans to allow ```
textwrap.dedent("""
text
""")
I'm not sure \ would ever need to be inserted by Black in such case though
closer to 2 years according to https://endoflife.date/python
oh right, gap between 3.7 and 3.8 releases was still 1.5 years
How do I prevent an exploded string from compacting back to a single line? Much like how function params can be kept as exploded by keeping , at the end.
Example:
foo: str = (
f"This is written on "
f"my {phone} phone, "
f"hope the formatting is OK."
)
If line length wouldn't be reached, it collapses it to a single line. What is the , equivalent here, at strings, to keep them exploded?
Thanks in front.
If an explanation of "why" is required, I am using the subprocess module and would prefer to write each shell command option/flag in its own line for clarity
I am aware that I can pass them as a list and that it is even safer that way, but assuming I only want to pass a single element that is a string and don't want black to collapse it
Please mention/ping me if you have a reply
# fmt: off and # fmt: on?
you don't (unless by turning off formatting)
Ah, that's slightly unfortunate
I have a general dislike for multi-line comments (indents considered, etc.), and "exploding" single-line comments are pretty darn sweet
Is your feature request related to a problem? Please describe.
When I raise a PR, I like to have the GitHub Action for black lint my code. However, with large projects, sometimes it's unwise to lint the entire existing codebase- it's better to only lint the files that have been changed in that PR.
Describe the solution you'd like
It would be great if there were an option to only lint the files that have changed, when running the GitHub Action on a PR.
**Describe altern...
Description
The original change no longer seems to be necessary for this.
Checklist - did you ...
- [ ] Add an entry in
CHANGES.mdif necessary? - [ ] Add / update tests if necessary?
- [ ] Add new / update outdated documentation?
Describe the bug
Black fails to parse valid code within a # fmt: off block.
To Reproduce
def testing():
print("world")
# fmt: off
print("hello"...
Describe the style change
In structural pattern matching, for sequence patterns, you can use either parenthesis, brackets, or just comma separated items.
Examples in the current Black style
Currently Black doesn't have an opinion and you can use any of them:
match actions:
case ["help", "bracket"]:
print("use brackets")
case ("help", "paren"):
print("use parens")
case "help", "comma":
print("just use comma")
...
The Resources page on our website contains a list of hand-selected learning resources that we regularly recommend to both beginners and experts.
Is your feature request related to a problem? Please describe.
The official psf/black GitHub Action does not seem to return information on its run. Other related actions such as https://github.com/rickstaa/action-black returned an is_formatted flag which could be used by subsequent steps.
If you use an "open pull request" action after the formatting step, and if black did format any file, then you can automatically open a pull request and when approved the formatted code would be co...
Is your feature request related to a problem? Please describe.
Our project contains symlinks like this:
project
+- a
+- b -> ../x/y
+- other files
+- x
+- y
+- lots of files
We would like to avoid black spending time formatting/complaining about the same files twice, so we make the excludes regex match /a/b/.
This doesn't help because the excludes are evaluated after normalising the path to /x/y/.
We cannot put that in the excludes because we ...
made a patch for this as it seemed to be "good use of my downtime" .. I did read contributing guidelines and pre-commits are passing but there's probably the idea needs some fleshing out even if it as accepted as feature for github action ..
3.9 -> 3.11
Description
Update the sentence indicating the latest version of Python from 3.9 to 3.11.
Presumably T:documentation and skip news.
Checklist - did you ...
- [ N/A ] Add an entry in
CHANGES.mdif necessary? - [ N/A ] Add / update tests if necessary?
- [ x ] Add new / update outdated documentation?
Not sure if a real issue nor if it is a known issue.
Black https://github.com/psf/black/commit/196b1f
...
Problem Statement
When binary operators, such as +, -, *, /, %, are used, their priority is given to them, and spacing should be set by their priorities. The stress could be seen when people write multiplication operators with some constants; they generally tend to drop the operator and write them together, e.g., 2*x becomes 2x.
Similarly, not just general logic but also PEP8 suggests following this priority style. However, Black does not recognize the prioritization of binary ope...
!d discord.AuditLogEntry.target
The target that got changed. The exact type of this depends on the action being done.
Description
Adds 2 new outputs to github actions which would allow pipeline maintainer to do conditional steps based on actions black did. These variables include is_formatted which defaults to 0 if no changes where made and 1 when files where formatted. Another one is changed_files, which defaults to 0 but reports the number of files changed during the action execution.
Checklist - did you ...
- [X ] Add an entry in
CHANGES.mdif necessary? - [X] Add / update tests i...
is there a good way to get pre-commit to use the nice mypyc compiled wheels?
Describe the bug
black --preview crashes on seeing await (yield)
This is certainly not good code or anything, but is code we have in one of our test files in flake8-trio. Non-preview black has no issues with it.
To Reproduce
For example, take this code:
async def foo():
await (yield)
And run it with these arguments:
...
I don't think so, @bright glacier has been thinking about how to make that work
Thanks for the contribution. Looks good. I think there is a few things we can clean up here tho. Lets try these, if any of my suggestions don't work, I apologize, just say so.
Fixes #3532
Description
Checklist - did you ...
- [ ] Add an entry in
CHANGES.mdif necessary? - [ ] Add / update tests if necessary?
- [ ] Add new / update outdated documentation?
oh apparently we're affected by whatever poetry did
wait what?
though it seems to have succeeded on psf/black so I guess not
Probably the cache is avoiding the issue. TIL isort uses poetry
Packaging is just โจ great โจ ugh
See PyCQA/isort#2077.
Description
Checklist - did you ...
- [ ] Add an entry in
CHANGES.mdif necessary? - [ ] Add / update tests if necessary?
- [ ] Add new / update outdated documentation?
^ might as well
the isort thing wouldn't be half as bad if..... pre-commit used wheels....
I also wouldn't have had to think about this :p
Honestly the general conclusion is that we'll have to set up a separate pre-commit mirror.
I am no way interacting with the pre-commit folks and as it stands there is no way for us to configure the hook installation flow enough to use a wheel from PyPI.
Thanks for submitting a PR but as it stands currently, this hurts UX in the general case. This captures the output of the Black invocation and never reemits it. That's already not great, but it gets worse. If Black errors out for some reason, the developer reading the logs will have no idea what's wrong since the logs will be almost entirely empty. There are two ways of fixing this:
- Reemit the captured output (always or on a non-zero return code; I'd prefer the former)
- Tee or someho...
226cbf0 Fix unsafe cast in linegen.py w/ await yield ha... - JelleZijlstra
@dense jungle any objections to requiring packaging unconditionally?
I want to merge the infer target-version PR soon (yes, actually).
as a runtime dep? I guess it should be fine since it's a light dependency
are we going to need a specific version range?
We're requiring 22.0 or higher. AFAIK packaging 22.0+ has no dependencies of its own.
I'll double check though.
โฏ pip install packaging==22.0
Collecting packaging==22.0
Using cached packaging-22.0-py3-none-any.whl (42 kB)
Installing collected packages: packaging
Attempting uninstall: packaging
Found existing installation: packaging 23.0
Uninstalling packaging-23.0:
Successfully uninstalled packaging-23.0
Successfully installed packaging-22.0
Yup. No dependencies, I remembered one thing that happened in the packaging space for once.
I mean, I'd prefer less dependencies too, but there aren't any good ways of avoiding it without severely degrading the feature. An extra would help, but its discoverability would be poor. I was also going to say that it could cause issues if some environments have packaging installed and others don't, but that'd be applicable to Black with this feature (aka 23+) vs Black without this feature (aka 23>=) so I dunno.
I think eventually, the general hope is that target-version is not configured explicitly for the vast majority of projects so it'd be best to support this by default.
FWIW, pytest and tox depend on packaging so it shouldn't be that bad of a dependency to pull in. Since Black is a development tool anyway, it's likely the environment already has packaging installed from some other dev tool. CI/pre-commit is the main place where this doesn't apply, but as packaging is so small it should be negligible.
Let's ship this! :ship: There some tweaks that will probably have to be made, but I'm sick of letting this rot anymore. I'll deal with them in follow up PRs.
It'll be really nice to have this in 23.1.0. Thank you so, so, so much @stinodego for baring with me.
@ ichard26 I addressed your comments, I think this handles all cases properly now. Happy to address any other feedback.
I would also be interested in doing some work as a follow-up to make Black use a single target version,...
Wait what, attrs doesn't specify Black's target-version? huh maybe that's why CI is failing on the PR...
Oh it is the reason why. Great.
Hmm okay, we need to tweak the logic in black/parsing.py too.
I was really tempted to merge the PR without taking another look at it, but I diff-shades ended up finding one more failure case. Wow this was complicated.
We're getting there. Just one more day and then 23.1.0 will be out.
PR looks good, although I think you can delete everything under this header. You might want to keep/move the "Improved empty line management" stuff to the stable docs though as subpoint 1 could surprise some people.
I need to investigate further, but this doesn't look ideal: https://github.com/psf/black/issues/3437#issuecomment-1407688550.
Man, looking at the assert-no-changes diff-shades results, django is going to get hammered by the new empty line logic.
It's like 98% empty line removals actually.
โญโโโโโโโโโโโโโโโโโโโโโโโโโโ Summary โโโโโโโโโโโโโโโโโโโโโโโโโโโโฎ
โ 15 projects & 1236 files changed / 4001 changes [+158/-3843] โ
โ โ
โ ... out of 2 394 690 lines, 11 482 files & 23 projects โ
โฐโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฏ
23.1.0 in a nutshell haha
Describe the bug
I have an odd use case for Black converting Qt Designer UI files to python code and improving the output.
I have found that doing each file in a new thread and calling black in a subprocess speeds up the process a lot.
Occasionally however Black fails to reformat one or more of the files.
`error: cannot format D:\Data\GitHub\Amulet-Editor\src\amulet_editor\plugins\amulet_team_home_page\home\home_home.py: [Errno 13] Permission denied: 'C:\Users\james_000\Ap...
packaging >= 22.0 should be relatively safe to depend on. I'll flag that 22.0 removed parsing for non-PEP backed version and whatnot, which triggered some folks to pin to < 22.0
Those things are gonna stop parsing after some time with pip and whatnot, so it's likely OK to just... tell them to not do that.
Thank you! This is great :ship:
Yeah AFAIK we just bail out and fallback to per-file target version inference if we encounter any errors. Non PEP-440 versions can just be ignored :)
Thanks for chiming in!
Hello, why can't black format strings and docstrings?
More context please? What are you trying to format?
i have pull request open against black github action (#3531) -- i wonder if anyone here would able to shed some light for windows use-case .. On github public runners the default sys.stdout.encoding is cp1252 .. If i capture the output (and convert to utf-8) - is it safe to still output the utf-8 string buffer as-is or should i convert that into corresponding charset ? on other words, does black honor the default output chararacter encoding when it reports its status after/during the run according to active char encoding or just blindly outputs stuff as utf-8 and hopes everyone will know how to deal with that ?
^ never mind .. there was some comments on the pr and im going to rewrite the patch
@dense jungle any objections to merging https://github.com/psf/black/pull/3393?
hm assert-no-changes is failing?
It does change the stable style, but it seems best to do it now than put it off as we are already changing the stable style.
Yup, we can move to the 2023 preview style. That also works.
yeah I'd rather this go into preview first. Doesn't seem like a common issue, or bad enough to rush a fix
I'm going to merge psf/black#3219 in a few hours FYI.
It's still failing assert-no-changes for attrs, but that's because of better inference of the target version (leading to the trailing comma being supported). Tying the feature to the preview style wouldn't make sense.
I also updated the docs in your 2023 stable style PR FYI.
oh thanks, was about to do that too but had to install prettier locally
In windows console emojis are replaces with [?] symbols
It is not powershell, it is cmd.exe
basically, cmd is stuck in stoneage era
this is a known issue
vscode set to format on save. Black seems to be working, and I've adjusted some settings.
But one I don't understand is that in my project README with spaces after list markers. Black seems to change the number of spaces to three vice one.
I suspect I'm missing a simple setting?
black only formats Python code
you are probably using some other formatter
Ahhh, good catch. I've never had the problem before and so I assumed it was Black since I had just installed it. But yeah, probably something else got changed in the process with Prettier.
Thanks.
I was feeling lucky
we may have to do a bit more clean up in the changelog in a separate PR
๐
Agreed, I was looking at it earlier while planning my blog post and it.. has some rough edges ๐
Hmm, did someone ask a question?
yay the FAQ turned out to be useful
I suggested it a long time ago on a hunch it would be useful, but I never got confirmation :>
I'll try to get my blog post wrapped up in 20 minutes.
anything I can help with?
if you're okay with it, landing psf/black#3219
otherwise, preparing the 23.1.0 PR (aka clean up the changelog) would be appreciated
ok I'll take another look at #3219 and then work on the changelog
Normally I'd try to preserve a good commit message before landing a PR, but time is of the essence right now so fair enough ๐
Byt why not 23.2.0, it's past UTC midnight
๐
Expectations.
Blog post is almost good to go. I'll put it on hold for the time being because it can always come out after the release :)
Time to cut 23.1.0 ๐
what is this UTC nonsense, PST is all that counts
I'm waiting for the isort hook to install, but otherwise your PR LGTM Jelle.
It seems likely that a lot of Americans would believe that about their timezone ๐
I am Dutch thank you very much
I am Canadian thank you very much x2
A lot of Americans may not know where that is so I'm not sure that counts
Anyway, so uh, are we missing anything? I think we're good. I wanted to take a look at psf/black#3437, but it seemed like it doesn't crop up often in practice?
Looking at the diff-shades results is mostly useless/unclear as it's dominated by blank line removals in other contexts.
I can't reproduce what they're saying ```(py311) jelle@m2mb-jelle py % black --version
black, 23.1a1 (compiled: no)
Python (CPython) 3.11.1
(py311) jelle@m2mb-jelle py % black --diff lines.py
--- lines.py 2023-02-01 02:42:44.654093 +0000
+++ lines.py 2023-02-01 02:43:35.755523 +0000
@@ -1,17 +1,12 @@
def run(self):
while True == self._doingathing:
-
if False == self._doinganotherthing: -
some = code if (am - pm) > self._doingthisthing: foo = bar if (me - you) > self.him: -
if self.canUpdate: -
while 1 < 2: foo += 1
would reformat lines.py
All done! โจ ๐ฐ โจ
1 file would be reformatted.
this looks fine to me
I wonder if the black playground is subtly broken.
Wait what, it's formatting differently than how I remembered last night. Ugh whatever.
@bright glacier do you want to do the actual release or should I?
I don't think it matters? Feel free to do it. I'm still tweaking my blog post
I have time if you need to step away though.
I will do it
should wait for CI on main to finish first though, docker is still running
good call
ok it's done
I did a test run of the mypyc workflow 1-2 days ago and it didn't go red, so it should just work this time. Hopefully.
and the macos tags should be for the right platform, right?
So I guess any fixes (I don't wish you any bugs but if) will go into 23.2.0 then?
I'll be asleep in 2 hours.
actually probably three
CI/CD is green so far, that's good. Phew.
and I get the right wheels on both an m2 and an x86_64 Mac
out of curiosity, why is gofmt in the repository tags for black?
I'mma take a short break. I've been sitting for too long. When I come back I'll do some announcements :)
I think it's been there since the beginning. The idea was probably that Black would be "gofmt for Python".
ah, in the opinionated thing. got it.
Docs are updated too, that's good.
Uhh did we actually make any changes in the 2023 stable style regarding strings? Apparently I noted it as something that got deferred because ESP got deferred in my previous post.
โฏ black --version && black /tmp/test.py --diff --color -q && black /tmp/test.py --diff --color --preview -q
black, 23.1.0 (compiled: yes)
Python (CPython) 3.8.5
--- /tmp/test.py 2023-02-01 04:05:36.985801 +0000
+++ /tmp/test.py 2023-02-01 04:07:14.765644 +0000
@@ -1,4 +1,4 @@
some_list = [
- ' lorem ipsum dolor sit amet consectetur adipiscing elit sed do eiusmod tempor incididunt ut labore et dolore magna aliqua Ut enim ad minim',
- ' veniam quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo',
+ " lorem ipsum dolor sit amet consectetur adipiscing elit sed do eiusmod tempor incididunt ut labore et dolore magna aliqua Ut enim ad minim",
+ " veniam quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo",
]
--- /tmp/test.py 2023-02-01 04:05:36.985801 +0000
+++ /tmp/test.py 2023-02-01 04:07:15.051024 +0000
@@ -1,4 +1,7 @@
some_list = [
- ' lorem ipsum dolor sit amet consectetur adipiscing elit sed do eiusmod tempor incididunt ut labore et dolore magna aliqua Ut enim ad minim',
- ' veniam quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo',
+ (
+ " lorem ipsum dolor sit amet consectetur adipiscing elit sed do eiusmod tempor"
+ " incididunt ut labore et dolore magna aliqua Ut enim ad minim"
+ ),
+ " veniam quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo",
]
Shoot, I should've caught this.
Well the best we can do is to fix the 23.1.0 changelog during the next release. I'll fix the other places right now.
GitHub Release? Not sure what release notes you're referring to.
yes
Already fixed. Blog post also fixed.
I'm annoyed I didn't catch that in review, but I'm also glad so far this has been the biggest mistake/oversight of arguably the most important release of the year.
Thanks a lot for all of the help @dense jungle. We got it in before February 1st even in my part of the world!
Hi, I'm using Starlark language (https://bazel.build/rules/language, a dialect of Python) for configuration files in a project.
I tried to run black on one file. It succeeded, but since it's a dialect and not "pure Python", I'm not sure it will work in any case.
My question is: is it safe to use Black to format Starlark files?
Thanks!
Sorry I forgot to check the channel.
So, I'm trying to format my docstring to keep it at 88 characters but black doesn't affect it.
And using Pycharm's formatter deforms my docstring. I'm using numpy docstring btw.
<!--
Please make sure that the bug is not already fixed either in newer versions or the
current development version. To confirm this, you have three options:
- Update Black's version if a newer release exists:
pip install -U black - Use the online formatter at , which will use
the latest main branch. - Or run Black on your machine:
- create a new virtualenv (make sure it's the same Python version);
- clone this repository;
- run
pip install -e .[d]; - run `...
<!--
Please make sure that the bug is not already fixed either in newer versions or the
current development version. To confirm this, you have three options:
- Update Black's version if a newer release exists:
pip install -U black - Use the online formatter at , which will use
the latest main branch. - Or run Black on your machine:
- create a new virtualenv (make sure it's the same Python version);
- clone this repository;
- run
pip install -e .[d]; - run `...
from https://bazel.build/rules/language#differences_with_python my guess is "mostly compatible", although "implicit string concatenation" might be a problem, esp with ESP
you're unlikely to get a guarantee from black, so i'd say if it works it works. from that list of differences i'm not seeing anything that would fail subtly
Thanks @elder tusk !
Is your feature request related to a problem? Please describe.
Black recently released v23.1 which broke CI builds due to needing to reformat everything to the new "2023" style of code (see also: https://github.com/psf/black/issues/3538)
Describe the solution you'd like
I would like to use v23.1 or higher and still maintain my old formatting to reduce churn and friction for new and old contributors to my project. This could be done using something like --style=2023 or `--st...

