#black-formatter
1 messages Β· Page 22 of 1
(the date isn't set in stone FYI, I just chose that on the fly)
oh I was holding down ctrl
I'm raising it within format_str so that's not really possible
Right, okay
emitting it against an explicit --target-version py27 is easy within the main function but it gets harder when source autodetection is the only way for us to tell
Although yeah, this would get messy with multiple files as multiple warnings would be emitted
I suppose we could set a global flag and then access it within main but I don't know how that'd work with multiprocessing as the format_str function doesn't have access to the manager object.
Well, format_file_in_place could get a manager parameter but that feels like overengineering at this point
Description
It's 2021. See also #2251.
Checklist - did you ...
- [x] Add a CHANGELOG entry if necessary?
- [x] Add / update tests if necessary?
- [x] Add new / update outdated documentation?
I wonder what's the chances I'll get angry comments saying we shouldn't do this ^^
The raw LOC currently in the codebase related to supporting Python 2 isn't actually that high (~200-400?) but it's the other assumptions and guarantees we won't have to hold anymore that is the major win. For one CI will get a lot less complicated as we won't have to run specific parts of the test suite twice, once with the python2 extra and once without.
Two, there's formatting decisions being impacted by Python 2 which is .. annoying to say the least.
I'm sure there's more but that's the main ones from my perspective.
Hi,
Question: Do you know of some "legacy code" migration cases to use Black as a formatter?
In the company I work for, we want to use Black for some old services but we want to know "success stories" in this type of migration.
Thanks for your answers (Black is a great tool!)
What are you looking for? I'm not sure what would be special about legacy code here. At various companies (Quora, Facebook) Black is being used to format millions of lines of Python, including some pieces of code that aren't frequently touched.
I mean if you have some recommendations for this type of migrations or if you know some common problems π
In my tests, the results are good but I wanted to know more cases (I have not found similar cases in my searches π€ )
Just run black, commit, and push π There's a bit more info at https://black.readthedocs.io/en/stable/guides/introducing_black_to_your_project.html
very incomplete haha
You donβt own me. I can merge if I want to. π
In seriousness, I +1 β¦ there is enough support with the current version for Python 2 syntax. It ainβt changing.
we all have the power to make the world burn by breaking all of the CI π
There also exists a Flake8 plug-in for use with black
Describe the bug
black panics on Apple Silicon
To Reproduce
Traceback (most recent call last):
File "/opt/homebrew/bin/black", line 5, in
from black import patched_main
File "/opt/homebrew/lib/python3.8/site-packages/black/__init__.py", line 13, in
import regex as re
File "/opt/homebrew/lib/python3.8/site-packages/regex/__init__.py", line 1, in
from .regex import *
File "/opt/homebrew/lib/python3.8/site-packages/regex/regex.py", line 4...
Big +1 for this and the whole timeline π
Description
You can now specify config key in pyproject.toml which does the same job as the CLI option --config. The path of config should be relative to the CWD it is running from. If the file is not found or is invalid i.e. it is a folder rather a TOML file it would raise click.exceptions.FileError, and if the file can't be parsed it would raise tomli.TOMLDecodeError. All black config keys in the custom config should be registered under [black] and they would overwrite th...
Description
Black would now echo the location that it determined as the root path for the project if --verbose is enabled by the user, according to which it chooses the SRC paths, i.e. the absolute path of the project: {root}/{src}.

Closes #1880
Checklist - did you ...
- [ ] Add a CHANGELOG entry if necessary?
- [X] Add / upd...
Lol, I am sorry for spamming 3 PRs. Had completed them before vacation and didn't get time to open them until now :)
Description
Woohoo! Module specific configuration! and a bit of restructuring of code in the black/__init__.py file. Mainly shifting all the "reformatting" logic to a separate function to increase the readability of code in the click CLI function. You can go through the code in the commit, code should be self explanatory, though I still need to update the documenta...
would be cool to do it at the same time with removing the beta also
In that sense the new year would be fit for purpose π
Eg I plan to remove 3.6 support in twisted 22 rather than 21.12
Even though python 3.6 is EOL in 21.12
Also you might want to consider a black21 pypi package so people can have both installed
How would that work? like rename the entry point?
Also I'm not too convinced it'll help much compared to them just pinning black that's bound to happen after we drop support
I doubt it would be happening in the same time but sure we could do that
No as in straight up another installable object
But what's the benefits?
And yeah it would need the entry point renamed
It would mean I could have both installed for when I'm working in say VSCode
But yeah I could just set two paths and have two virtual environments
It's going to conflict with a newer version as they would have the same package name and entry point
No they'd need to be renamed package and entry point
Yeah maybe it's not so useful
I suspect you'll see one emerge anyway
Yeah but given we strongly recommend pinning black hopefully less?
Right but it's about being able to have both in one virtual environment
I just don't like it as it feels like people are going to come up and claim we will have to support it indefinitely as people will rely on that compatibility trick
You could even have black[python2] just require black21 and run black21 when you have a python2.7 target version
But yes we could do it
Then you could remove the python2 parsing today
I suppose it's still less of a maintenance burden since we won't be doing any feature developed on such a black21 project but I will bet some packaging stuff will go wrong one day and we'll be asked to fix it
I don't use Python 2, so I'm unbiased
But yeah I hate to be in the position to ask for an extension, it's just to make the version number pretty
I honestly don't really care for Python 2 as I've literally never used it.
Wow
I've pretty much only done large scale 2 to 3 migrations, very little actual feature development
I don't have Python 2 code to even migrate ignoring some bug cases people have sent in for black
I haven't been in the Python scene for too long haha
Same π
But yeah, dropping beta at the same time was just a quick suggestion, doesn't really matter when we do it
Is this related to a problem? Please describe.
I am aware from the issue tracker of the "magic comma" whereby a trailing comma can sometimes influence what black does, but cannot see where this is documented - e.g. https://black.readthedocs.io/en/stable/faq.html#
Describe the solution you'd like
Have the "magic comma" documented.
Describe alternatives you've considered
I have browsed the issues but haven't hit on a succinct summary.
**Additional conte...
What's wrong with December π
It would be 21.12b0 right?
I get the major version increment though :D
Fixes #2394. Eventually fixes #517.
This is essentially @pradyunsg's suggestion from #2394. I suggest that at the
same time we start the formal stability policy, we take a few other disruptive steps
and drop Python 2 and the "b" marker.
I see no reason to wait.
Also, people and CPU architectures ... Thanks for inflicting this on us Apple.
The cogs are turning and it's exciting! π As discussed, the policy is sensible. And having a CLI flag instead of, say two branches with different release lines seems more manageable.
i often see that when writing this:
some_function(some_other_function(tuple), another_function), # my long comment that the formatter doesn't like
the autoformatter does this:
some_function(
some_other_function(tuple), another_function
), # my long comment that the formatter doesn't like
i would prefer it to do this:
# my long comment that the formatter doesn't like
some_function(some_other_function(tuple), another_function),
is black safe to use on production code?
yep black should error out if the ast is different from the original
(it shouldnt actually change the ast)
Don't run it on your production server though
Unless your production server is running the black playground
A few suggestions inline, and a note.
Define this stability policy as something that applies to the stable releases, not all releases. I would also recommend against making any formatting changes when this policy is adopted -- it would be a good idea to have a beta release prior to the stable release, that contains any potentially disruptive changes. IMO your last beta release and first stable release only have one difference -- the version number -- that's how you know it's good enough ...
Wow a metric ton of stuff happened while I was alseep and then busy. I'm still busy unfortunately but in 2.5 hours I'll try to get caught up and get reviews dealt with.
I suppose my action to deprecate Python 2 convinced you @dense jungle to stop us from sitting around and doing nothing about the stability problem ^^
And thank you for that by the way! I wouldn't have done that personally as it's not really my domain.
Hyy
Hi
Well it looks like black is switching to semver that also happens to be calver
Describe the bug
Python 3.10 keywords aren't recognized
To Reproduce
Run black when match keyword is present in the file
For example:
- Create a file
sample.pyhavingmatchkeyword - Run
black -l 80 sample.py - See error -->
error: cannot format sample.py: Cannot parse: 2:10: match option:
Oh no! π₯ π π₯
1 file failed to reformat.
Expected behavior
Black formatter should format 3.10 related syntax/keywords too.
**Environment (...
Thanks for submitting the PRs! This one looks the easiest to review out of the bunch so I'll be tackling this one first ^^
I know this is a minor feature but this should at least get a changelog entry as it is an user-facing change.
Also, why do we want to emit a message with the sources passed on the command line? I don't see how it's useful and it can be a bit confusing in some cases like this:
~/programming/oss/black/docs on branch feat/project-root-verbose [$?] via Pyth...
I'm not the biggest fan of the refactor in this PR: https://github.com/psf/black/pull/2527
Yeah our configuration and options handling code needs some work but it's hard figuring out what's supposed to be the refactor and the feature addition.
There's some things of the refactor from a quick skim I don't like, but whatever those are fixable. What's not fixable is the commit history. I really would have hoped the refactor would've came in its own commit but nope.
Not sure what the pipfile.lock changes are about, but they're definitely broken
OK, I just went over most of the changes that happened over the 24 hours. Is this a correct summary of the current situation?
- Formatting Python 2 will be deprecated in the next release
- Formatting Python 2 support will be removed right on January 1st, 2022 (because people still treat CalVar as SemVar for the most part) as part of a normal beta release (22.1b0?)
- On the same day or soon after we adopt the stability policy and publish a stable release containing only documentation changes and a version bump (22.1.0?)
@drowsy sonnet you should probably read this as a general rundown from what I can tell. The main thing I'd put up for debate is when the removal happens. I originally targeted December 1st, 2021, but some people have said doing it in a "major" release would be less confusing ... which is frustrating but understandable.
Honestly I don't feel strongly about the date, but thought it'd be useful as an indication that Black 22 will be a clean break to some extent
Fewer things for users to remember if last beta version == last Python 2 version == last 21 version
Yeah I suppose. I do like Pradyunsg's idea that the stable release should be as simple as possible to really indicate we're going stable, but it would make the Python 2 removal more confusing with the current timeline.
Maybe we release 22.0rc0 first, then 22.0.0 hopefully unchanged
basically my rundown but with a rc marker instead of the beta marker haha
got to use all the available options in versioning π
maybe we throw an 22.0a0 in just for completeness
So wait we are in agreement and I just am misreading all of this? π there's nothing to debate
I thought there was haha. I still do think Pradyunsg's suggestions are overall a good idea but I don't think they're controversial.
Yeah, we just turn on ESP without telling anyone in that release
and format everything using tabs and single quotes
speaking of that, what's the game plan with ESP? We'll need to get it landed before we adopt the stability policy or else it's going to be tabled for a year π
There's still the performance issue. I can try to find some time to figure it out
π₯
Cooper also recently ran into an issue where it doesn't format well, I think you were also on that thread
Yup, something about function calls not respecting user defined splits even though that's part of the ESP rules.
what's funny is that we call the blib2to3.pytree.Node.update_sibling_maps method so much in that bad case the built in id function makes up a significant fraction of the runtime IIRC
Yes there's something quadratic, last time I looked into it I wasn't able to figure out how to fix it π¦
I tried for a little bit and I couldn't either π¦
@tired shard hello!
(it took like 5 minutes to figure out what your discord username was π)
ah they're busy and off discord for the time being
Yeah CalSemVer for the win π But a yearly release cycle doesn't seem that bad so I'm all for it. We got to pick some number anyway if we want to promise stability.
Hi. It's Friyay.
Let's merge everything π₯³
There's no reason to stick with CalVer if you really want SemVer. You can just switch. Version numbers are cheap. π€·
I do like the idea of a yearly cycle still, switching to SemVer completely would just mean more major releases along the year I guess.
The main benefit of anchoring to the calendar IMO is the ease of planning of changes.
That's why pip is anchored on the year.
Idk where the Dec 1st date came into being (I aggressively unsubscribe from issues, because... uh... 1k unread notifications is bad enough). I wouldn't promise a date.
Just say Python 2 is deprecated and will be removed in the first stable release. And also note in the stability policy that you're adopting annual formatting changes; without making formatting changes as part of the first stable release.
If you cut the stable release in Feb 2022 or April 2022, nothing is going to break. Give yourselves the flexibility to do things at whatever pace, instead of promising deadlines to largely ambivalent users.
That's my 2 cents anyway.
Don't get into a situation where you promise a removal and then don't do it
Eg what CPython do, it means you lose trust
Fair enough ππΏ
But also people need to see black as a free gift not as something with an SLA that just went down
Published https://t.co/7aBaPVdevu
Both maintainers and users of open source packages have been thinking about backwards compatibility the wrong way -- too focused on the procedural issues and not enough on the substance of if we're spending our breakage budgets well.
Hmm interesting!
The foo he's talking about parsing is an X.509 certificate and the database is on the computer of every person in some reasonably large country
Richard also raised a good point about chaining this value in the original issue. I tend towards chaining being supported, which would require a loop of some sort to follow the TOML files.
Also, I think it would be more consistent to just require all TOMLs to have the same structure, i.e. a tool.black section instead of some other magical section. That way we could probably reduce the implementation to recursion, which wo...
For what it's worth, I don't think my proposal really is "CalSemVer": we promise no changes in formatting, but that doesn't mean no other new features. For example, we'd still be able to land Jupyter Notebook support or Python 3.10 support in the middle of the year.
The guarantee is just that if Black formats your code right now, it will keep formatting it the same way for the rest of the year
Yeah that was a bit tongue in cheek anyway π but to be fair, semantic does allow to add features in minor versions. Now if we want to make breaking changes to other than formatting mid year that's a different discussion, and I think we should be able to as long as it's communicated, which the changelog will do!
It also gets messy when we introduce an official API for black - now SemVar could have two distinct meanings (one is more obvious but it's still not great)
Yeah true, the guy advocating for semver on the policy issue had good points but I also feel like it isn't worth it to switch
hi, I am amateur, i need a road map for begin python tutorial, do u have some good refrences to read ?
Hey there! Youβll get an answer to that question over in #python-discussion. This channel is specifically for the black formatter tool
FYI this is very off-topic here as this is a topical channel about the Black autoformatter project. Not sure what's the server's position on advertising / promotion, but this isn't the right place for this.
Sorry! I thought it's for all opensourse projects.
Just logged onto discord and 23 pings lol after a month. I would be "fully" active from this Sunday thought π
And sorry for the XXXX, my nitro expired and I didn't know my ID
Description
While working on shed, I discovered that feature detection for positional-only arguments doesn't work in lambdas, though the docstring of get_features_used() suggests that it should. I've therefore added syms.varargslist to the check, and a test case which demonstrates that it works.
Checklist
- [x] Added a CHANGELOG entry
- [x] Added test cases
- [x] This change does not need documentation
I should really get back to working on diff-shades because enforcing no formatting changes without something like mypy-primer is going to be a pain.
!remind 1D Get back to work on diff-shades
Your reminder will arrive on <t:1634089012:F>!
Did you mean:
remind edit duration
remind edit mentions
remind edit content
remind edit
!remind delete iirc and make new
!help remind edit duration
!remind edit duration 3261 18H
!remind edit duration 3261 18H
That reminder has been edited successfully!
:)
there, jeez lol
I'm bloody staff and I still can't get the reminders command right :p
could you please hit the trashcan on some of those help messages? π₯Ί
since they're so big
seriously
it takes up my whole screen
happy now?
well, no, technically I'm never happy.
sigh, how are you then today?
monotone
relatable
I haven't written code for my project in days.
just.... fixing a bunch of workflow problems π₯²
Haha yeah, the debugging experience with GHA is not great to say the least
thankfully I haven't started on those yet
tbh I expected a reaction out of you lol
more like, wrote some more scripts for pre-commit
yellow not an interesting colour for ya?
my short term memory sucks so that's understandable ^^
Technically it's my undershirt or whatever
lol
i've basically reimplemented stuff that poetry does into a pre-commit script
I was invited a long time ago but I only recently accepted staff.
I- .. why tho
because poetry has like either 50 or 100 dependencies and my script has.... one dependency.
i already use pre-commit so that's not a problem
and even so, the script can be run alone
(I know this because I've checked black's CI setup and pre-commit is responsible for like 50% of the installed test dependencies)
we don't even use pre-commit in CI so yeah π€·
it also takes like, 20 seconds less than poetry π₯²
it's for halloween
tldr rather than submit a pull request to fix poetry I would rather use pip and a bunch of hacks to get around it
halloween
got any good nick suggestions for halloween?
nice
brb
...itchard?
yes i was gone just to think of that
wow i am smart
-that's how I pronounce my nick matter of fact
I don't like it when people call it "i-chard" for personal reasons, hate how it sounds
never thought the other one
wait what are you talking about?
Is this "chard" pronouned with a hard ch or like "card"?
The one you dislike
ok, I've always mentally pronounced it i-card
Wee helloe, richard could you see the msot recent comment on the --verbose PR
wheee 
welp time to go back to dealing with merge conflicts
i mean fun times
seriously i just wanna code again π’
everyone's favourite pasttime amirite /s
yes
i have so many
sooooo many workflows and stuff i want to do
but the end goal will be so worth it
It's pretty late over here ~10 PM so I'll have to take a look tomorrow but sure.
just a few clicks and a new version is on its way on docker, read the docs, pypi, etc
!remind 18H also look at the --verbose latest comment from Jason
Your reminder will arrive on <t:1634068451:F>!
Alright, that's fine
hello jason, could you take a look at the configuration pr? π₯Ί
I would be scared about the automation breaking with that much
I commented in workflow thread arl, using release feature of github to publish on pypi, docker, run tests, discord notification, etc
if it does I'll be ready to fix it
but like, black already has pypi and docker scripts
so you copied and pasted, heh π
yeah, just catching up with all the development on my contribution projects
that
one sec
these are a thing
so I'll set up a workflow that makes a new branch, runs some things, commits it, and then opens a pr
probably*
Yup yup I've used workflow_dispatch before
not that complex though haha
yeah i might not do that too
the key reason i want to do it is in case i need to make an urgent bugfix release while not at my pc and unable to use git
the joys of Python C extension compilation
that's fair. I wouldn't provide that kind of response time guarantee since well.. I'm just a volunteer on the interwebs but you do you
yeah
i honestly
likely won't make that full workflow
and if i do, its much later in time
like, when there's not much else to do
hmmm
while i'm thinking about all of this, and er, which channel we're in
I have to realise, I've almost never thought about my formatting
since nearly the very beginning of the project
honestly the more I program the less I use black consistently
oh?
Yeah, I used to run black on all of my scripts and whatever, but nowadays I don't run it nearly as much because there's some elements of the style I hate a lot.
yeah, i had to turn its format off for a line of my code
Mostly with breaking on the LHS vs RHS and how nested brackets are treated
scripts/export_requirements.py lines 26 to 33
# fmt: off
MESSAGE = textwrap.indent(textwrap.dedent(
f"""
NOTICE: This file is automatically generated by scripts/{__file__.rsplit('/',1)[-1]!s}
This is also automatically regenerated when an edit to pyproject.toml or poetry.lock is commited.
"""
), '# ').strip()
# fmt: on```
Oh yeah and that's another wish item
putting more than one function on a single line
that's probably not a good idea to enforce consistently though
(i'm kidding of course, this line isn't actually super genius)
but i like what i did here π
Hi guys, i use black in vs code. I want to disable it putting trailing commas, how can I do the same?
I am not sure if this is correct, I just added the arg --skip-magic-trailing-comma into my black args in vsc
Nope, still not working
That's not what --skip-magic-trailing-comma does. By default, Black uses trailing commas in the input as a signal to split up lines; with that flag it doesn't. There is no flag for not adding trailing commas.
Here's your reminder: Get back to work on diff-shades
[Jump back to when you created the reminder](#black-formatter message)
get to work!
ugggh I am super busy with other stuff today
same!
lol i was opening diff shades
and ended up on next-pr-number
again
where is the source for diff-shades?!
Here's your reminder: also look at the --verbose latest comment from Jason
[Jump back to when you created the reminder](#black-formatter message)
ichard26/black-mypyc-wheels
ah okay
How would use see what black formats exactly
Iβm not a 100% sure what youβre asking, but I think youβre looking for the βdiff option
Run black in pipenv shell command line.
% black kueh.py
error: cannot format kueh.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 helpful: /var/folders/qs/vt7pvr2d3mlctnlr3zs52q3w0000gp/T/blk_vt7wm5xo.log
Oh no! π₯ π π₯
1 file failed to reformat.
To Reproduce
- Take this file 'kueh.py'. [kueh.py.zip](https://github.com/psf/black/files/7336314/kueh.py....
Does this adhere to PEP 8?
Black? Yes!
So is there a way to solve the problem of not adding trailing comma?
Black should always add a trailing comma if a collection is split into multiple lines
Yes, I dont want it to do that, can I disable it?
I could so it from source but I think that would be redudant just for trailing commas and I would like to get updates on black
No, Black is generally not configurable
Oh well, thanks
what even was that
good question
Why would you want this behaviour?
!json
When using JSON, you might run into the following error:
JSONDecodeError: Expecting value: line 1 column 1 (char 0)
This error could have appeared because you just created the JSON file and there is nothing in it at the moment.
Whilst having empty data is no problem, the file itself may never be completely empty.
You most likely wanted to structure your JSON as a dictionary. To do this, edit your empty JSON file so that it instead contains {}.
Different data types are also supported. If you wish to read more on these, please refer to this article.
@bright glacier i've finally remembered I can make issues so other people can do things π₯²
awesome
Can someone give me a project, one which use python+ dbms/file handling
Describe the bug
Black couldn't format a file in my project, generating code that does not equal the source.
To Reproduce
error: cannot format black_error.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:
value=
Constant(
kind=
None, # NoneType
value=
- 'I ...
I hate when people disregard templates
Wait, do we have an option to not look for a configuration file?
Hey guys, how can I disable black to do this? Its too short and just adds extra lines to the code and makes it confusing
As Jelle said yesterday, Black generally isn't configurable π
As the line gets longer and there are a few arguments, breaking the line is much more readable
Is your feature request related to a problem? Please describe.
Given that Black always looks for a configuration file, up to the file system root (!), it could be convenient to be able to explicitly not look for any configuration files. This would be advantageous when debugging different options.
Describe the solution you'd like
$ black --config -
$ black --no-config
Or maybe I've just missed it, didn't look at the code yet. In which case it should be document...
I wish we could specify after how many parameters it would break the line
It wouldn't really be consistent, because long lines would have to be broken anyway. Line length is the way to go in my opinion at least
Okay, maybe we could have both
We appreciate the ideas, but the whole ethos of Black is to limit the number of style choices a user has to make. We're quite opposed to adding configuration values like that. It's nothing personal, and I also sometimes feel like some other style would be better in certain situations. But overall it isn't worth the inconsistency. But it's nice to see you're interested in improving the style! If you think something should definitely be formatted differently in most cases, feel free to open a discussion on the issue tracker (after checking similar ones of course) ππΏ I hope I'm not too dismissive also π
I've modified the bug issue template slightly to:
- Make it more explicit that we want the user to check if the bug is already fixed, rather than finding out that it isn't reproduced on
mainand submitting the issue anyway - Provide an example formatting of the reproducing example's components, and not hide it in the HTML comment
Checklist
- [x] Add a CHANGELOG entry if necessary?
- [x] Add / update tests if necessary?
- [x] Add new / update outdated documentation?
Maybe this will help π
why not yaml templates? They are more easier to work with
Oh, I didn't know they allowed yaml too, I'm looking at the guide just now!
Or did you mean the issue forms?
yeah
You should use forms, yeah
Isn't there PR open for it by any chance though?
Or at least issue
I recall seeing one
Can't find one at a quick glance
Guess I misremembered it then
https://github.com/discord-modmail/modmail/blob/main/.github/ISSUE_TEMPLATE/bug_report_bot.yml Aru made a good one here, if you want some reference.
Also, https://github.com/psf/black/pull/2526#issuecomment-939711852 if you get sometime. I applied your suggestions and even added relative project path to all file references. And wanted to ask about one more change of output "levels" like logging levels which give it default styles
Yeah we really need other maintainers to pitch in too. I kinda like the colours, but it's better to keep PRs focused on one issue ππΏ
Yeah, I would push this to a separate issue later, others would probably agree with you there, verbose enhancement changes soon
Hi! I'd like to work on issue https://github.com/psf/black/issues/2370, one thing is I'm not sure where to start. Any advice on where I should look to catch blank lines after docstrings and where to implement its deletion?
Hi! Thanks for considering a contribution π€ But as it stands, the issue is not resolved yet, meaning that there is still discussion to be had particularly from the maintainers.
But lemme give my 2 cents there now
biiiig can of worms lol
especially with people already having issues with the little changes done by Black since it's AST unsafe
yeah π
but well, technically it's a bit of off-topic for that issue since it was just about whitespace outside the docstring lol
so no AST safety issues involved there at least
definitely in favor of no blank lines after myself π
when it comes to the multi-line doc vs single-line doc, I also agree with how you formatted it yourself: ```py
def f():
pass
def f():
"""Doc."""
return stuff
def f():
"""
Multiline doc.
With some explanation.
"""
return stuff
Rather than the:
```py
def f():
pass
def f():
"""Doc."""
return stuff
def f():
"""Multiline doc.
With some explanation.
"""
return stuff
but well, that's entirely separate thing
and there's probably some open issue about it already lol
yeah, I checked numpy's style guide and there it was actually as in your second example
which I was quite surprised by
yep
I sometimes have to do ```py
def f():
"""
Very long doc that would not pass length limit in a single line if I did not add the new line.
"""
return stuff
rather than this because it didn't pass line length in this specific case:
def f():
"""Very long doc that would not pass length limit in a single line if I did not add the new line."""
return stuff
But it always seems off
definitely not my preference for things that can fit in single line
technically could just do a split just so that it doesn't look weird:
def f():
"""
Very long doc that would not pass length limit in a single line
if I did not add the new line.
"""
return stuff
but if it's unnecessary to pass line length, it feels like I just am doing it so that I can look at it lol
I guess it could be the time to shorten the initial explanation and just elaborate in a full paragraph
Sometimes it might be hard to shorten the initial explanation
or at least that's my feeling
We have a lint rule enforcing that you have a one-line summary for your docstring
Bug description:
Black deletes nonempty block comments before decorators left unfromatted with #fmt: skip.
As a legitimate real-world example (unlike the minimal test case I present below), I found this when black unexpectedly removed an # endregion comment in between two unit tests, the second of which was decorated with @parameterize. That decorator was skipped with fmt: skip to allow me to group/align rows of arguments.
For me right now, this is mostly an annoyance, ...
wow the fmt: skip implementation seems buggy then π
Describe the bug
Crashes on MWE below.
To Reproduce
class myclass:
def run(self):
while True:
if True:
a = something(
[],
[], # very important that comment stays here
[]
) # fmt: skip
Sometimes --skip-magic-trailing-comma can help with your kind of example
Thanks
I prefer the second codeblock π
But that should be in like a description. I've had similar cases myself of course and I get where the problem is though.
!d del
7.5. The del statement
del_stmt ::= "del" target_list
``` Deletion is recursively defined very similar to the way assignment is defined. Rather than spelling it out in full details, here are some hints.
Deletion of a target list recursively deletes each target, from left to right.
Deletion of a name removes the binding of that name from the local or global namespace, depending on whether the name occurs in a [`global`](https://docs.python.org/3/reference/simple_stmts.html#global) statement in the same code block. If the name is unbound, a [`NameError`](https://docs.python.org/3/library/exceptions.html#NameError "NameError") exception will be raised.
!e
lst=[1,3,4]
del lst[1:1]
print(lst)
@viral path :white_check_mark: Your eval job has completed with return code 0.
[1, 3, 4]
Describe the style change
Examples in the current Black style
def f():
"Make sure this code is blackened"""
pass
Desired style
def f(
):
pass
Additional context
Hmm
Trying to repro 2540, but so far it doesn't seem to be crashing
It's insisting it's python 2 though, don't know if that's related
Oh wait I didn't have a clean branch π€¦ββοΈ π€¦ββοΈ π€‘
ignore all I said
(Still not crashing on a clean branch)
Well, managed to finish off that bug, but found a more interesting one
jpadilla/black-playground#49
Describe the bug
When trying to format a document in Visual Studio using the black formatter, an error is thrown when there is no newline at the end of the file. Please see https://github.com/microsoft/PTVS/issues/6752 for details.
To Reproduce
- Create a python application in Visual Studio
- Paste the following code (no newline at end!)
# this is a comment
import os
import sys
spam(ham[1], {eggs: 2})
def foo(): pass
x = 1
y = 2
y = 2
# comment ...
huh.
As I rewrite diff-shades I'm replacing my custom DIY output format and tooling for rich. I regret nothing because it looks way better already π
That's really pretty, keep it up
My original thinking was something along the lines of "oh diff-shades is going to be too slow to require fancy output" but I forgot that the other maintainers have 6-core CPUs with each core being much faster too (or something similarly fast) π
lol
I'm just sitting here with a dual-core AMD APU from 2015
the github actions runner is actually faster than my machine AFAICT
diff-shades is going to be too slow to require fancy output
I would think that this is a good reason to have the fancy output
since that way you can see progress
I mean, my original output already had a custom percentage indicator
Status update. Looks great imo :)
/me needs to find a way to get higher quality screenshots and screen recordings ...
That is beautiful!
Thank you! I still have a few more things I want to tweak but I'm close to finishing the first command implementation ^^
Is that open source?
diff-shades? Yes, it's a tooling project for black so we can more easily compare formatting differences between two versions of black!
hence diff (reference to the diff format used for comparisons) and shades (as in shades of black)
... although I'm yet to publish it, I can quickly do that if you'd like to explore the code ^^
I'd love to see it, although I'm in no rush haha
here ya go: https://github.com/ichard26/diff-shades
once you cloned and installed it (I recommend in a venv) you can try this example command: diff-shades analyze example.json -s "black" -s "blackbench" -s "bandersnatch" (it shouldn't leave any artifacts, although if it does lemme know!) (actually as I reimplement more functionality, example.json will be saved FYI)
tyty
oh and you can pass --verbose to see how I handled verbose output ^^
thank youu! 
Nice, mypy caught a subtle programming error! I accidentally append-ed a dict to a list even though I should've been appending a tuple that contains such dictionary.
black-formater xDD
I found this and it seems like a great way to cut back on the "cancel workflow" when repeatedly force-pushing
Hm, it probably won't work for what you described since the ref will be changing, but modify that part, and yeah it'll work
We actually have it on PRs for pydis projects
I'm not actually going to use it for the time being as I have write permissions to psf/black and I don't mind the clicking (after all I have to deal with failure notifications)
Yeah I just realized that, whoops :p
Do you get them on PRs 
failure notifs that is lol
Yup, only on my commits though, it'd be painful for all of them π
Well there go my plans for sliding into your emails
I'm sure my email is somewhere out there in the interwebs
I think you signed it over when you made your blood sacrifice contract to join staff
But where's the fun in that
But yeah lol, just imagine getting a GHA failure email in which the log output is "hey $name, wanna grab lunch later?"
lmfao
Oh I completely forgot about that
Anyways I'll stop bothering you before I get a warning for derailing this channel π₯²
Yeah OK, I'm sure you could find it on notion
f.warn 386599446571384843 
(that's my python bot's prefix)
I am on the test server π€‘
Does black follow sub-poetry project's configs rather than taking the top level config?
atm I essentially have one config inside a folder and black seems to be defaulting to using the nested config not the top level config from where it's ran
the other offender is flake8 but its harder to tell whether it's the culpret or not
Not currently, but there are issues on the tracker discussing something like that: psf/black#1826
ah, thanks shall have a read.
Describe the style change
See also: #90
Black currently forces blank lines after all imports, including imports outside the "import section" at module scope. I find that this yields super inappropriate results. Black does not have enough context (outside the module-scope "import block") to know whether adding a blank line will correctly denote intent or enhance readability. Black should refuse to guess; as in #90,
Example input
I'm having trouble generating a good exa...
oh hi Marco, I see you're typing something π
Anyone had a chance to look at https://github.com/psf/black/issues/2516 and have a second opinion on whether this should be fixed in black or upstream in ipykernel?
Hmm, my immediate reaction is that if they're going to patch sys.std* they should support as much of the io.TextIOWrapper API as possible, but I assume this issue has existed for a long time and probably won't be fixed?
totally off topic, on the IPython repository I got this unfortunate message:
A user youβve blocked has previously contributed to this repository.
π
π I think I remember Anthony Sottile saying that some user he'd blocked had contributed to some Richard Stallman support project on Github, and Anthony said he was glad he'd gone ahead with the block
(also totally off topic of course)
The person I blocked was just annoying with their relentless IMO spammy issues but nothing too serious other than wasted time and effort
Is there an issue about OutStream not having the buffer attribute somewhere? I tried looking (hence why I learned the user I blocked contributed to IPython) but I couldn't find one π¦
I think this would be in ipykernel rather than ipython - if I start an ipython session, then sys.stdout has a buffer attribute. If it's in a Jupyter Notebook, then it's an ipykernel.iostream.OutStream object and has no buffer attribute
I haven't found this reported in ipykernel either - perhaps I'll investigate a bit more then report it when I get some time
The output black gives to me when the value of a dict item is made up of two consecutive string literals (on different lines because of the line length limit) is ugly enough to look like a bug to me:
--- STDIN 2021-10-18 20:25:48.108927 +0000
+++ STDOUT 2021-10-18 20:25:52.127191 +0000
@@ -1,5 +1,4 @@
d = {
- "key":
- "this entry is a long string."
- "lalala this is the next part of the long string lalala"
+ "key": "this entry is a long string."
+ "...
β
reported it to ipykernel
thank you!
Can I use black on an entire package?
Absolutely! I run it on projects with at least a dozen files often.
How do you do that?
I'm trying to have black auto format everything on github actions
I typically run it locally, and then add black in CI just to make sure it was ran locally (so without modifying the code in CI).
Off the top of my head, I believe the args I'm thinking of are --diff --check
What's CI?
I'd like to run it via GH Actions so anyone who makes a PR has it auto-formatted as well
CI is continuous integration, think GH Actions
I'm not sure how the commit via GH actions, but I know that it's possible
Ah
You might be able to use https://pre-commit.ci 's ability to autopush formatting fixes
@solar totem ^^ (I forgot to mark my message as a reply)
Huh
This whole automation with github actions is wildly confusing
I want to release a new PyPi release when I make a new GH release, I want to run this testing file, and all sorts of other things
You can totally do that, it's just annoying to setup a workflow that'll automatically push a commit
We have workflows for testing, doing a PyPI release, building various support files for the release, and linting, so it's certainly doable ^^
Yeah, it's all just very confusing
Fundamentally it's basically just running a pre-defined series of steps on some server (usually from the cloud). Actions are just pre-built steps in a way, they can be as simple as checking out a repository to as complex as handling a full build of a suite of wheels.
This is a little off-topic for this channel though, I'd suggest #tools-and-devops for more discussion or help.
although something that is on-topic is this example github actions workflow we have in the docs:
name: Lint
on: [push, pull_request]
jobs:
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: psf/black@stable
with:
version: "21.5b2"
(and Jelle before you @ me for using an old version, it's the first one that came to mind as a valid one π )
That makes three of us
You can make GitHub Action make a commit for you
There are even some pre-built actions for it:
- name: Commit changes
uses: stefanzweifel/git-auto-commit-action@v4
with:
file_pattern: pyproject.toml
commit_message: Bump version to ${{ github.event.release.tag_name }}```
You should be using both precommit with the black hook and GH actions ideally
haha
Description
Looking through this again, I think a lot of it's unclear, and there's some repetition, so here's a little refactor
Checklist - did you ...
- [ ] Add a CHANGELOG entry if necessary? NA
- [ ] Add / update tests if necessary? NA
- [ ] Add new / update outdated documentation? NA
Description
Checklist - did you ...
- [ ] Add a CHANGELOG entry if necessary?
- [ ] Add / update tests if necessary?
- [ ] Add new / update outdated documentation?
Docs job in CI is currently failing, as Sphinx 4.1.2 doesn't support Python 3.10
Describe the bug
I have installed Black using vim-plug. Installation is successful and I can update the plugin no problem. However when I run black inside Vim I get the following error
Error detected while processing /Users/scott/.vim/plugged/black/autoload/black.vim:
line 195:
Traceback (most recent call last):
File "", line 97, in
ModuleNotFoundError: No module named 'black'
Error detected while processing function black#Black:
line 10:
Traceback (most recent call ...
hm what's this
black formatter
Describe the bug
Black fixes line with length of 116 but doesn't fix line with length of 121. When i tried to fix it myself Black reverted my changes.
To Reproduce
- Take this code:
def temp():
datetime_start_result = f'{datetime_start[6:10]}-{datetime_start[3:5]}-{datetime_start[0:2]} {datetime_start[11:]}'
datetime_finish_result = f'{datetime_finish[6:10]}-{datetime_finish[3:5]}-{datetime_finish[0:2]} {datetime_finish[11:]}'
- Run Black on it with...
Description
Run the formatter twice to ensure stability.
Fixes #2488 and #2518
Admittedly, it doesn't fix the underlying issue. There are three
expected-failure tests in test_black.py, which prove the issue
(test_trailing_comma_optional_parens_stability{1,2,3})
This is a (somewhat terrible) bandaid which runs the entire formatter
twice to work around this problem. This bandaid actually already existed
in the stability-checking-validation code, but resulted in a non-stable
...
TBF I actually think a cli option to run black twice and alert of any changes would be nice loll
But it shouldn't be like that π
The only reason you'd want that is the stability issues, so it'd be better to fix them. Granted, they aren't fixed
Hi π Would love to get some more reviews on psf/black#2526 psf/black#2525
Hello !
Do you know if there is any way to make black support formatting to match pydocstyle ?
http://www.pydocstyle.org/en/6.1.1/index.html
We try to not touch docstrings too much. Although personally I'd be in favor of normalising their style as well π But doesn't pydocstyle itself support many styles?
Looking better already, here's some comments:
Describe the bug
A line like
bla(
sheet=[p.row + p.timestamp for p in players[:args.cutoff]]
)
is turned into
bla(
sheet=[p.row + p.timestamp for p in players[: args.cutoff]]
) # ^ space introduced here
This upsets flake8, which complains:
E203 whitespace before ':'
Environment (please complete the following information):
- Version: 21.4b2-1 (Debian)
- OS and Python vers...
https://github.com/psf/black/pull/2525#discussion_r732652768 @errant barn I am not sure if you understood it right there, what I meant was when black would come across config it would overwrite all the config on the main pyproject.toml with that found in the config specified in config.
So that test would do the same thing, where it just keeps a few vars in the main config and all of the original ones in test_black.toml(current name) and then would see if the values are from test_black.toml and not from the main one
Sorry, I find it hard to read this message as well, let's go over it :D
So the previous tests parse_pyproject and read_pyproject asserted that 1) the values are read correctly and 2) they are carried over to the top level function being click friendly
This change introduces the ability to specify config to link to another file. So in my opinion it should be a separate test.
Maybe it should be the other way around, that the new file uses this test.toml as the link target.
Ok, so say the pyproject.toml contains:
[tool.black]
a = 10
b = 20
c = 30
config = "black.toml"
now we specified that the config for black would be present in black.toml and like discussed on github we would just overwrite the config with the one found in the linked file i.e. black.toml
[tool.black]
a = 20
b = 30
So, this is the content of black.toml, that test is testing that the values a which is 10 in the main config is overwritten to be 20 which is found in the linked config.
--
Yeah, the original test goals are conserved here, it just edits adds an additional before giving it to the top level function and reading the main config
Maybe it's just preference, but I don't like the idea of deleting simple tests just because more complex tests cover those cases too
I get what it does though
How about this?
That way we wouldn't have to make two new files, just one with the link
its not deleting them (if deleting means the thing below, i am adding them back, i removed them earlier as i added them as two separate tests but now kept them as one as the original functionality has changed)
umm could you share an example, i am not sure if i correctly understand
The two tests are different right: parse and read. You removed some attributes from the parsing test, which now covers less values. Or am I tripping? :D
ah i get it, the attributes which are deleted aren't meant to be deleted and I am pushing a change to fix that.
They aren't there as they were required for a previous functionality which was removed and then i forgot to apply the change here,
Yes, please leave this test as it is and create a new one with the linking
I think just a single test is ok though, which "reads", not "parses"
but I like the idea of checking that they are overwritten ππΏ
π yeah will mention that in a bit
btw is black participating in hactoberfest, as in can contributors get hacktoberfest-accepted label on their pr
I can't add the hacktoberfest topic FYI only ambv can IIRC
so we'll have to use the accepted level
I think that's fine :D
we have to use the accepted label anyways if the repo has the label or not IIRC (i haven't looked into this year's rules)
it's not like our review cycle is faster than issues and contributions π
But what's up @bright glacier, howya doing?
you are, but it has been indeed moved up
Quick question about formatting :
If you have a really big integer (for example, 0xAA87CA22BE8B05378EB1C71EF320AD746E1D3B628BA79B9859F741E082542A385502F25DBF55296C3A545E3872760AB7), how should you write it ?
Should you just write it and ignore the 80 characters line limit ? Or is there a special way of writing integers to respect this limit that I'm not aware of ?
Not completely sure for numbers, but itβs certainly okay to go over the limit in blackβs style if you have to
With a bytes literal
Well.. The bytes literal is EVEN BIGGER that the original integer...
But you can split it
Well, yes. But it'd be a bit confusing I believe. I think it'd be more readable to just have one big integer rather than a bytes string
*But it's a good idea, thank you
If repo has a topic, you can either label, approve, or merge
If no topic, only label works
Describe the bug
Black throws an error trying to format files containing a parameter assignment with a generator. This is valid Python code.
error: cannot format util.py: Cannot parse: 200:43: if any(match := pattern_error.match(s) for s in buffer):
Oh no! π₯ π π₯
1 file failed to reformat.
To Reproduce
Code sample:
if any(match := pattern_error.match(s) for s in buffer):
if match.group(2) == data_not_available:
# Error O...
π is it possible to add them to my PRs?
we'll do it on merge!
cool thanks
Black does not work on 3.10 for mac?
I believe it should run but it doesn't support all 3.10 syntax
Running black on 3.10 throws this error
That's an M1 issue I believe, there's an open issue about iit
Okay
Thx for the help π
Been busy with life and pretty stressed that way, but I am managing. Got plenty of work to do so I doubt I'll have much time to dedicate to psf/black.
Oh yeah, since last time we interacted I've become PyDis staff ^^
Oh damn, more power to ya for managing the stress πͺπΏ and nice that you're on PyDis! π
hey you're technically on PyDis too!
We'd still have to rewrite all of Black to work with libcst π±
What about an # black: off that literally snipped the lines until # black: on?
sigh we got a long story to tell here :(
Then pasted them back after format
How is that different from # fmt: off?
it wouldn't require black's parser to support the snipped out code
currently we still parse the whole file and then turn any marked code into standalone comments (internally) which aren't touched by the formatting logic
Yep
Then you'd do the ast check after
And it would be the authors fault if they built something that can't work
It would be brittle but probably work in a lot of cases
I saw that isidentical hacked up match statement support for blib2to3
I saw that isidentical hacked up match statement support for blib2to3
The format comment would have to match the indentation
Has anyone looked further into that yet?
Wow magic
oh I didn't know that, that sounds great
Can you imagine JavaScript standardising something that wasn't supported in all their type checkers and formatters
Javascript standardises things that don't even have support in any of their implementations every once in a while
Ah yeah that one thing
But they changed the standards process pretty much because of that
And that's why I skipped implementations in my rant
hm
lol
if i want to do something cursed I probably shouldn't be doing
i want to set black to format one folder with one line length
and a different folder of a different length
in the same project
lol
there's an open issue exactly for that
My 3rd PR π
Description
It currently prints both ASTs - this also
adds the line diff, making it much easier to visualize
the changes as well. Not too verbose since it's only a diff.
Especially useful if the test file is long (and the ASTs are big)
Checklist - did you ...
- [x ] Add a CHANGELOG entry if necessary? (should not be necessary for this)
- [x ] Add / update tests if necessary?
- [x ] Add new / update outdated documentation?
π
Morning y'all
Morning π

Good Afternoon
I think the EU should mandate a line length as well as a phone/laptop charger type
Where do I sign? π
π
Describe the style change
I suggest to use explicit string concatenation, instead of implicit concatenation, for (currently experimental) string processing, with whitespace pushed to the end of each line.
Examples in the current Black style
(
"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 ali...
ugh
Repro steps:
- Create the minimal jupyter notebook, which will contain one cell with the function ands a comment, containing question mark;
def example_fn(param):
"""
param: str what to print?
"""
print(param)
- Close the file and run
black-nb Repro.ipynb
The error will be shown:
error: cannot format /path/to/nb/Repro.ipynb: INTERNAL ERROR: Black produced code that is not equivalent to the source on pass 1. Please report a bug on https://gi...
Using question marks for params? That's a new one
yay for spammy reviews :(
This seems to be an nb specific issue
Could not reproduce with just black
No one from the team has ever been involved with black-nb
Thanks
They probably should intercept that error message and put their bug tracker lol
confirmed that issue was in fact with black-nb
Also did a whole bunch of debug for them for free π€‘
thanks for digging into this @tribal thistle !
I was just messing around, it's actually fun
Description
Makes it possible to run a subset of projects on black primer
Checklist - did you ...
- [x ] Add a CHANGELOG entry if necessary?
- [x ] Add / update tests if necessary? (Added tests!)
- [x ] Add new / update outdated documentation? (CLI documentation gets inlined)
Description
Only black_primer needs the disallowal - means we'll
get better typing everywhere else.
Checklist - did you ...
- [x ] Add a CHANGELOG entry if necessary? (should not be necessary)
- [x ] Add / update tests if necessary? (not needed)
- [x ] Add new / update outdated documentation? (not needed)
Description
I removed these and found that mypy still passed (particularly since it's hard coded to target python 3.6 currently)
Checklist - did you ...
- [x] Add a CHANGELOG entry if necessary? (not needed)
- [x] Add / update tests if necessary? (not needed)
- [x] Add new / update outdated documentation? (not needed)
da8a5bb Disallow any Generics on mypy except in black_p... - nipunn1313
I think it does make sense of boolean parameters
Description
This adds a minimal set of changes to use black under pypy. It's supposed to be a more acceptable version of ...
with the key point being there are zero changes for cpython users.
This is a draft - feedback appreciated - I plan to do all of the following (if needed):
Checklist - did you ...
- [ ] Add a CHANGELOG entry if necessary?
- [ ] Add / update tests if necessary?
- [ ] Add new / update outdated documentation?
Nice issue
github is an issue indeed
Is this related to a problem? Please describe.
On Black's future style doc it talks about black handling a with with multiple context managers in a few ways (Python-version-dependent).
Describe the solution you'd like
Black should suggest to the user (in documentation only) that if they don't like Black's current or future behavior, that constructing a `c...
Describe the style change
Currently, if an if-expression within a function call needs to be broken across lines to avoid being an overly long line, it gets put horizontally in line with arguments which makes it hard to see where each argument in the call begins.
Examples in the current Black style
yield Test(
test_path=trimmed_path,
expected_text_path=expected_text_paths[-1]
if expected_text_paths...
Description
Python 3.10 final is already tested, just needs the Trove classifier.
Checklist - did you ...
- [ ] Add a CHANGELOG entry if necessary?
- [n/a] Add / update tests if necessary?
- [n/a] Add new / update outdated documentation?
Is a changelog entry needed?
By the way, Black was first released in March 2018 and took the forward-thinking view to only support Python 3.6, which was the newest release, and therefore Black hasn't needed to drop ...
Thanks for the idea /addition. I feel this is already achievable tho. Via config files.
Whats the use case and advantage of this over just making a dedicated subset config file(s)?
- I guess so you can have a large config file and only run some projects
But I feel if you're doing that a lot just having multiple config files would also work. But I get de-duplication is nice.
Interested to hear so I can understand more. Thanks!
supporting a program across three OSes and five Python versions is quite a bit. Even my tiny diff-shades project's CI looks complex in a way haha :)
One thing I don't like about using pre-commit with mypy is that unfortunately the mypyc compiled wheel isn't used. Slows down linting more than necessary but I doubt pre-commit would accept a Python specific feature to pull from PyPI.
produce error
error: cannot format /Users/SOROKAN6/projects/idse-pqsar-api/tests/test_ellipsize.py: INTERNAL ERROR: Black produced different code on the second pass of the formatter.
run black for the file and it will show the error.
but there is impossible to attach py-file
Environment (please complete the following information):
black, version 21.8b0
Python 3.7.6
MacOS 11.6
Does this bug also happen on main?
No
Additional context
[blk_9gtrwz8w.log](htt...
Hey @golden mica!
Uh-oh! It looks like your message got zapped by our spam filter. We currently don't allow .txt attachments, so here are some tips to help you travel safely:
β’ If you attempted to send a message longer than 2000 characters, try shortening your message to fit within the character limit or use a pasting service (see below)
β’ If you tried to show someone your code, you can use codeblocks
(run !code-blocks in #bot-commands for more information) or use a pasting service like:
Oooh I just discovered difflib can reverse a diff
Pretty handy when all you've got in an issue is the diff lol
wait what, what do you mean 
something
- a
+ b
something
difflib can take ^ and convert it to just:
something
a
something
or just
something
b
something
basically apply the reverse of a diff and give you back the two inputs
oh wow
!d difflib.restore
difflib.restore(sequence, which)```
Return one of the two sequences that generated a delta.
Given a *sequence* produced by [`Differ.compare()`](https://docs.python.org/3/library/difflib.html#difflib.Differ.compare "difflib.Differ.compare") or [`ndiff()`](https://docs.python.org/3/library/difflib.html#difflib.ndiff "difflib.ndiff"), extract lines originating from file 1 or 2 (parameter *which*), stripping off line prefixes.
Example...
I do wish difflib could apply a diff though
ups missed this
?
It was pretty much a hacky solution, so not something I'd say useful
but can be revived for simpler use cases
Eh, Εukasz already said he'll be looking at your hacky solution π
π
[ambv] I will be looking at Batuhan's match:case: hack (https://github.com/isidentical/black/commit/c22fca62bdeca503ef1fa56647b410cbd3d5af81) to see if we should be including it
[ambv] it's not The Solution for 3.10 support but might buy us some time
I wonder what would happen if we threw a fuzzer at this "solution"
I think the only case it currently doesn't work is match match: or case case: in terms of PEP 636.
I'm pretty sure it can be implemented though did not try to work on it
Regarding fuzzing, I've used this script;
import ast
import sys
from pathlib import Path
with open(sys.argv[1]) as stream:
tree = ast.parse(stream.read())
functions = {
func.name: func
for func in ast.walk(tree)
if isinstance(func, ast.FunctionDef)
}
test_dir = Path("/tmp/patma_black_tests/")
test_dir.mkdir(exist_ok=True)
for name, node in functions.items():
with open(test_dir / f"black_{name}.py", "w") as stream:
stream.write(ast.unparse(node))
to extract all pattern matching cases from https://github.com/python/cpython/blob/main/Lib/test/test_patma.py
and then run this to estimate how much percentage of those my hack support;
from pathlib import Path
from collections import Counter
from black.parsing import lib2to3_parse
test_dir = Path("/tmp/patma_black_tests/")
counter = Counter()
for file in test_dir.glob("black_*.py"):
try:
lib2to3_parse(file.read_text())
except Exception:
stat = "fail"
else:
stat = "success"
counter[stat] += 1
print(f"{file.stem}: {stat}")
print(counter)
(just throwing, in case it would be useful for future effort)
Yup yup. This is way out of my wheelhouse haha, so I'll cc @solid adder who actually knows something about parsers ^^
Thanks for the work by the way, I'm rather impressed and this might end up being useful!
The only things I can sorta understand about parsing is tokenization and whatever grammar blib2to3 uses. I once tried writing a recursive-descent parser .. it didn't go well π
that's why we have such great parser generators (pgen2 /pegen), throw the grammar get the parser π
Yeah, I wanted to learn how parsers worked by writing one by hand, turns out it was harder than I expected π
CPython's grammar is pretty complex now, ay? definitely wouldn't want to maintain its parser by hand
indeed
Poll time! please vote on which one looks better (hint: it's all about the bold styling)
!poll "First or second one?" "first" "second"
π¦ - first
π§ - second
Other suggestions welcomed too πΊ
mmm if only difflib could do image collages
haha yeah, I'll figure something out when I implement a show commabd
haha yeah, I'll figure something out when I implement a show command
the only difference is the bold font on the text between time and the square brackets/parentheses?
yup
..... looking for the differences
it's the bold font / regular font in the upper output
ooooh, I just saw that, wow
since this is so colorful, I'd go with bold
also, I am totally using this as an inspiration for my build system :P
.bookmark Black's fancy output
this is technically not black's output, but diff-shades' output - which is a tooling project to collect and display differences between versions of black
100% courtesy of the beautiful rich library β¨
Rich is gud
I still don't know what I am using to make my build system
I could try some bash for the sake of it, but I already regret it
Bash scripting is something I'll continue to ignore π
haha
I did some basic scripts, I have some very useful ones, like https://github.com/Akarys42/kissland/blob/main/postgres/generate_database.sh
I just love that one, despite being so basic
the only "shell scripts" I have are my various aliases
alias lexa "exa -lga"
alias actenv '. env/bin/activate.fish || begin; . venv/bin/activate.fish && echo "... but venv did work!"; return; end;'
alias sl "sl -elF"
alias blackenv ". /home/ichard26/.local/share/virtualenvs/black-Q9x7i-w-/bin/activate.fish"
alias wb "python -m webbrowser"
alias addpythons 'set -x PATH /opt/python3.7.8/bin/:/opt/python3.9.5/bin/:$PATH'
straight up aliases, not functions?
yeah, okay
that's cool
Fish user, I dig this
actenv makes me happy as I don't have to do . /venv/bin/activate.fish constantly πΊ
well, I don't have a very high opinion of fish, but it is the less worse one
I don't have aliases, just autocomplete haha
understandable
diff_shades/cli.py:208: error: Incompatible types in assignment (expression has type "str", variable has type
"Union[Literal['nothing-changed'], Literal['reformatted'], Literal['failed']]") [assignment]
for type in ("nothing-changed", "reformatted", "failed"):
``` well that's annoying but understandable
hmmm right windows unicode support is still a pain
aren't the two the same 
nope, check the font
Ah ok
not relevant to the channel ^^
yuh that's reason why i use fish
@upper pollen Hiiii!!!
I'm a bit annoyed that it takes too much time to format a single file when using black to auto-save contents in my IDE (in this case it's Eclipse/PyDev, but I guess it should be the same for any place using the command line to format a single file).
-- In Eclipse/PyDev, the integration (I've done) is done so that for each new file to be formatted, black is executed and contents are piped in/out.
For doing this execution (in my machine), black takes 0.3s, but out of that time, 0.255s...
Describe the bug
As a Developer using the Click library, I often use the docstring formatting control character slash-b and slash-f as described here: https://click.palletsprojects.com/en/8.0.x/documentation/#preventing-rewrapping
When I use black to reform my code, black will "right shift" the content in an unexpected and undesired manner.
To Reproduce
Create a Click command using the control formatting:
def cli_design_report_interfaces(devices: Tuple[str]...
Black doesnt support python 3.10
It crashes on match-case code
When this support will be added?
--- diff_shades/config.py 2021-10-26 01:33:59.410935 +0000
+++ diff_shades/config.py 2021-10-26 01:39:34.119995 +0000
@@ -42,15 +42,13 @@
"django",
"https://github.com/django/django.git",
custom_arguments=[
"--skip-string-normalization",
"--extend-exclude",
- (
- "/((docs|scripts)/|django/forms/models.py"
- "|tests/gis_tests/test_spatialrefsys.py"
- "|tests/test_runner_apps/tagged/tests_syntax_error.py)"
- ),
+ "/((docs|scripts)/|django/forms/models.py"
+ "|tests/gis_tests/test_spatialrefsys.py"
+ "|tests/test_runner_apps/tagged/tests_syntax_error.py)",
],
python_requires=">=3.8",
),
Project("diff-shades", "https://github.com/ichard26/diff-shades.git"),
Project("flake8-bugbear", "https://github.com/PyCQA/flake8-bugbear.git"),
I .. do not like this formatting I got by turning on ESP 
-the brackets were explicitly added to increase clarity and that's gone now
It's tough to say as our parser library might need to be fully swapped out to support the new fancy PEG style grammar (and the syntax it allows eg. the match statement). There might be a hack we can do in the mean while but we haven't looked too much into it yet.
.rw-rw-r-- 109M ichard26 ichard26 25 Oct 22:18 full.json
... that is one big analysis data file from diff-shades π
Have you heard of json is not a database π³
yes.
i do not care
it's only 10000 serialized dataclass objects that make up the file π /gen
did I tell you that this file could get even bigger π
I think I'm going to have implement some basic optimizations to help keep the file size a bit more manageable.
!d sql
Although it's really compressible so it's the not worse in the world: that file is 17MB as a zipfile :)
no.
Source code: Lib/sqlite3/
SQLite is a C library that provides a lightweight disk-based database that doesnβt require a separate server process and allows accessing the database using a nonstandard variant of the SQL query language. Some applications can use SQLite for internal data storage. Itβs also possible to prototype an application using SQLite and then port the code to a larger database such as PostgreSQL or Oracle.
The sqlite3 module was written by Gerhard HΓ€ring. It provides a SQL interface compliant with the DB-API 2.0 specification described by PEP 249, and requires SQLite 3.7.15 or newer.
I have never used a proper database before tbh
same tho
Describe the style change
i found black will split arr[1] to a wired format
Examples in the current Black style
some_arr[
1
]
Desired style
some_arr[1]
Additional context
Black https://github.com/psf/black/commit/62ed53
The MRE below shows the issue pretty clearly, I think, but there's also a [Playground][playground] available.
The docs state:
fmt: on/off have to be on the same level of indentation.
So this kind of single line block should be okay, shouldn't it? #fmt: skip didn't work for me, either.
For what it's worth, I came across this issue in a Docker...
thoughts on this formatting?
I agree it's nicer with the parentheses
Alright time to stretch my triaging muscles and see if I need to open a new issue π
... it's been a while :)
2697074 Refactor Jupyter magic handling (#2545) - MarcoGorelli
aedb4ff Print out line diff on test failure (#2552) - nipunn1313
Sure, agree. This is indeed a dev tool.
467efe1 Add --projects cli flag to black-primer (#2555) - nipunn1313
huh, there's now a github command palette, neat!
Haven't debugged yet but seems a build level bug inside the container. Need to see if it can be reproduced locally.
error: failed to solve: process "/bin/sh -c pip install --no-cache-dir --upgrade pip setuptools wheel && apt update && apt install -y git && cd /src && pip install --no-cache-dir .[colorama,d] && rm -rf /src && apt remove -y git && apt autoremove -y && rm -rf /var/lib/apt/lists/*" did not complete successfully: exit code: 1
Error: buildx fail...
Future note for once the build is fixed: you can get the build running on PRs too, so you don't have to discover this when you merge into main.
With some caching, it shouldn't be too bad
Could I get rereviews on my PR :D
I'm going to be busy for this entire week. Sorry, hopefully someone else can pick up your PRs.
also oh my goodness your cats Jelle π₯°
Describe the bug
If a windows directory junction is found while crawling a source root, and it points outside of the source root, then black will error. This happens even if the directory should be ignored!
To Reproduce
- Start a windows cmd prompt
mkdir source_rootcd source_rootmkdir .gitmklink /J dir_junction ..python -m black --exclude dir_junction .
Then you get this error:
Traceback (most recent call last):
File "C:\pytho...
I guess I'll have to learn what a directory junction is
I'll take a look hopefully
If the individual failures are verbose, it's useful to have
the summary at the end. Otherwise, it can be really difficult
to figure out which projects have an issue.
Checklist - did you ...
- [x] Add a CHANGELOG entry if necessary?
- [x] Add / update tests if necessary?
- [x] Add new / update outdated documentation? (not necessary)
And our dependencies are still on fire π
Which repo would that be targeting lmao
## Can I run black with PyPy?
Yes, there is _experimental_ support for PyPy 3.7 and higher. You cannot format Python 2
files under PyPy, because PyPy's inbuilt ast module does not support this. For the most
stable user-experience, we recommend using CPython if possible.
hmmm
ah, dupe PR, https://github.com/psf/black/pull/2559
maybe against their fork?
a little farfetched I admit
Description
Fixes #2488 and #2518
Consistently apply paren omission rules regardless of existence of magic trailing comma. Previously, the first run would expand + add a magic comma, and the second run would get a different paren omission rule, causing black to be unstable. We had some hax in black/init to work around this which this diff removes.
This changes the way black formats (adds more parens in some cases). Based on the black release stability policy, we'd want this t...
Run black in a while loop till the output does not change
/s
||unlessβ¦||
Then run a different formatter, just to triple ensure no changes made.
Thanks! Will leave this for @cooperlees to also comment.
Sure. This only helps and regresses nothing. I just used grep and found it easy to workout things.
5434407 black-primer: Print summary after individual fa... - nipunn1313
.rw-rw-r-- 109M ichard26 ichard26 28 Oct 16:54 full.json
.rw-rw-r-- 12M ichard26 ichard26 28 Oct 16:58 full.tar.bz2
.rw-rw-r-- 17M ichard26 ichard26 28 Oct 16:57 full.tar.gz
.rw-rw-r-- 9.8M ichard26 ichard26 28 Oct 16:59 full.tar.xz
eh with compression it's not too bad @plain atlas
although to be fair --xz is extremely slow and --bzip2 is a fair bit slower than gzip
Smh
?
Conflicting files
- mypy.ini
- src/black/init.py
- src/black/linegen.py
- src/blib2to3/README
- tests/test_black.py
well that's annoying >.<
git rebase main -i
oh gosh test_black.py has five conflicts π¦
i don't even know how it has this many
psf/black#2431
(I own no MacOS running machine)
π good person
I completely forgot we added a --workers option
whyyy do we have so many options nowadays π
i want black to have a lil bit of plugin support someday
or i might hack it in to a script and set that to my path
Doesn't that go against the general philosophy
honestly some days I just want to give up and merge fundamentally bad changes into the project
because people will constantly ask for them regardless of what you do
lmk when, i will 100% make a fundamentally bad pr
psf/black#6912
format black with yapf
- 6534, - 12004
Ran black through yapf, think the results looks nice.
No idea why the diff is like that, also it stopped working
.<
is running two commands too much?
yes
mostly because i can set vscode to format on save but i can't set vscode to sort imports on save and doing it manually is so much work ;-;
then again
one sec
you can, for example, set vscode to run pre-commit on save. Then, if you have isort and black and everything there in pre-commit, you're laughing π
I think I resolved the conflicts, hopefully a local test suite run passes and then the mypyc compiled one too π€
they were super sketchy to resolve
ugh, the new test_projects primer test is super slow
21.51s call tests/test_primer.py::PrimerCLITests::test_projects
0.43s call tests/test_primer.py::PrimerLibTests::test_gen_check_output
0.01s call tests/test_primer.py::PrimerCLITests::test_help_output
(2 durations < 0.005s hidden. Use -vv to show these durations.)
``` that's not OK
what the hell
src/black/__init__.py:1311: error: unused "type: ignore" comment
src/black/__init__.py:1313: error: unused "type: ignore" comment
oh for goodness sake
i'm done for today, nothing has gone well so far
Taking a break is a good idea
**If anyone wants to be really nice to me by doing a favour then please read the following:
**
Right now the test suite is a bit fragile and some tests break when the CWD isn't the root of the project. And while usually this isn't a problem as tox and most people would run pytest from the root, it's not guaranteed. I'm working on getting Black compiled with mypyc and the test phase of automated wheel build is currently crashing as the CWD isn't set to the project root (by design of pypa/cibuildwheel).
It'd be awesome to not have to fix this myself as it's mostly just uncomplicated maintenance which sometimes I don't really feel like doing. All you should have to do is setup a development environment, cd into tests/ and run pytest and boom you should see quite a few failures π
Thank you!
I shall attempt to debug this. This is on the main branch correct?
Mhmm.
If you don't feel like setting up a full development environment simply setting up pre-commit and a virtual environment + python -m pip install -r test_requirements.txt should get you all set up for debugging.
Not using pipenv?
You can also use pipenv but I honestly don't trust it that much haha π ... and would totally understand if someone felt the same way
Ah fair enough, I don't love it either
Note that you'll have to install black with the jupyter extra.
Is it mostly ModuleNotFoundErrors or did I set up something really wrong?
uhhh that doesn't seem right
All I did was activate a venv and run python -m pip install -r test_requirements.txt
You also did a local install (python -m pip install .[jupyter]) right?
errr, no. woops
should've clarified that, whoops my bad
woohoo, is this right?
Err, this only worked without the [jupyter]. Do I need that part?
well some the CWD sensitive tests need that extra
I now realize there are some contrib docs, maybe I should read them.
nope, nope, apparently I got everything misremembered.
python -m pip install .[jupyter,python2,d] is actually what should work (did not remember we had so many dependencies required for testing)
Sorry for the trouble dawn. I was expecting this to be easy and simple but turns out no :(
but yeah this should work as I've just tested this locally:
python -m virtualenv venv- activate it somehow
python -m pip install .[jupyter,python2,d]python -m pip install -r test_requirements.txtcd testspytest
tyty
if this doesn't work, I- don't even know
failures due to mismatched CWD should look similar to this
I assume this'll involve a lot of the THIS_DIR = Path(__file__).parent and ROOT = THIS_DIR.parent pattern
erm, did I screw something up?
ah yeah, I encased it in quotes and it worked
That's probably why my installations were failing
Thanks!
Yep learned that the fucking hard way
wait why is zsh doing a bunch of random things holup
But also
So uh, for a couple of these tests, it seems like these errors are coming from Path().cwd(), so is it just a matter of trying if it works and then going up a directory and trying again if it fails?
Rather than fixing the problem, what about sidestepping it
And determining the project root directory, then changing the cwd to that dir
I was thinking to just hard-coding the root of the project
That would be nice, actually
You do realise that's not possible, is it?
So just a BASE_PATH and calling everything based on that?
The root would only be true on one machine
THIS_DIR = Path(__file__).parent
ROOT_DIR = THIS_DIR.parent
Got it, makes sense
And then every path would be constructed from one of those two?
yup, pretty sure we do that in other parts of the test suite
lemme find an example
Yknow
Ooh, yeah, you have it in tests.util, I shall look at that
that seems like a bad idea
Smh
tests/test_black.py lines 186 to 196
def test_piping_diff_with_color(self) -> None:
source, _ = read_data("expression.py")
config = THIS_DIR / "data" / "empty_pyproject.toml"
args = [
"-",
"--fast",
f"--line-length={black.DEFAULT_LINE_LENGTH}",
"--diff",
"--color",
f"--config={config}",
]```
there's an example, although the base is the tests directory instead of the project root
There's a PROJECT_ROOT in test.util, I'll just import that when necessary
And...?
What's the different between these two tests if I'm using the project root as a base? Can I just change the pyproject_path and get rid of the second?
huh
I just don't really understand the difference between those, besides the .parent in the second.
It seems like the former is all about finding the pyproject.toml in the CWD while the latter is focused on the finding one in the parent (hence the forced switch to tests via that context manager)
I need a moment to read the code tho
I have no idea why pyproject_path = Path(Path().cwd(), "pyproject.toml").resolve() is returning /home/ichard26/programming/oss/black/pyproject.toml even when the CWD is tests/ though
what if we get the cwd and the tests path, and merge them to form the relative path?
IIRC most of the tests are failing due to that tests/ path right?
yeah well
because they're relying on the relative path root to be ./ aka project_root
If I understand what you're saying, that's what is being done.
pyproject_path = Path(Path().cwd(), "pyproject.toml").resolve()
```was changed to```py
pyproject_path = PROJECT_ROOT / "pyproject.toml"
```for example
Yeah, so we get the cwd and tests path, then we can merge them, i.e. if the path is a/b/c and you are in a it would get the difference b/c/ (merge is not the correct word π€¦ )
Honestly I don't even know what these tests are testing
excessing data
blame scale
yes he did write the tests lol
They're well documented tests, really.
anyway, the reason why test_code_option_config is failing is because there isn't a pyproject.toml in the tests directory
>>> from pathlib import Path
>>> Path('tests/data').relative_to('tests')
PosixPath('data')
something like this
Yeah, I replaced that with test.util.PROJECT_ROOT to fix that
The second line here
so when CWD is set to tests/ the expected configuration path contains tests but black's automagical searching of parent directories meant it found the project's root configuration
(instead of just blowing up)
ah, I see
this can be done to fix the errors which are shown when tests/data is not found if your PWD is tests (etc)
another way to fix the test would be use the change_directory context manager and force the CWD to root so the spirit of the test case is preserved but that's probably not super duper important
I can do that, I don't mind
I find this more confusing then just hard coding the relevant used data file.
example:
______________________________________________________________ test_ipynb_and_pyi_flags ______________________________________________________________
def test_ipynb_and_pyi_flags() -> None:
nb = os.path.join("tests", "data", "notebook_trailing_newline.ipynb")
result = runner.invoke(
main,
[
nb,
"--pyi",
"--ipynb",
"--diff",
],
)
assert isinstance(result.exception, SystemExit)
expected = "Cannot pass both `pyi` and `ipynb` flags!\n"
> assert result.output == expected
E AssertionError: assert 'Usage: main ... not exist.\n' == 'Cannot pass ...ynb` flags!\n'
E - Cannot pass both `pyi` and `ipynb` flags!
E + Usage: main [OPTIONS] SRC ...
E + Try 'main -h' for help.
E +
E + Error: Invalid value for 'SRC ...': Path 'tests/data/notebook_trailing_newline.ipynb' does not exist.
test_ipynb.py:455: AssertionError
an easy fix would be to replace
nb = os.path.join("tests", "data", "notebook_trailing_newline.ipynb")
# w/
nb = DATA_DIR / "notebook_trailing_newline.ipynb"
ah I didn't see that DATA_DIR existed in utils.py
So once I get this worked out, I should just open a PR, correct?
Yup!
I'll try to review it soon after but I can't make promises as this week is a bit tight.
How would I go about using those utils to replace os.path.join()?
I'm not completely sure on that.
this is a relevant example, no?
I tried that, it still failed
uhhhm
Wait a minute... it succeeded right above, I probably screwed something up
ah, forgot to str() it
The last test I'm having trouble with is this one, and it's because the message doesn't match here. Does anyone have any ideas on this? https://github.com/psf/black/blob/main/tests/test_ipynb.py#L346
tests/test_ipynb.py line 346
r"File 'tests[/\\]data[/\\]notebook_which_cant_be_parsed\.ipynb' "```
May help unblock #2431
Checklist - did you ...
(none of these necessary)
- [x] Add a CHANGELOG entry if necessary?
- [x] Add / update tests if necessary?
- [x] Add new / update outdated documentation?
Nevermind, I got it to work by making the message into an f-string and using DATA_DIR in that too
Description
Fixes the issues described [on Discord](#black-formatter message).
At the moment, tests break when they're run from a directory that is not the project root. Specifically, tests/. This makes changes to use the PROJECT_ROOT, THIS_DIR, and DATA_DIR constants defined in tests.util so that tests will be runnable from multiple locations.
Checklist - did you ...
- [x] Add a CHANGELO...
Fixes @ichard's comment in https://github.com/psf/black/pull/2555#issuecomment-954284259
Runs in 0.4 seconds rather than 8 seconds previously (on my machine).
Checklist - did you ...
(none needed)
- [x] Add a CHANGELOG entry if necessary?
- [x] Add / update tests if necessary?
- [x] Add new / update outdated documentation?
Description
Checklist - did you ...
- [ ] Add a CHANGELOG entry if necessary?
- [ ] Add / update tests if necessary?
- [ ] Add new / update outdated documentation?
Currently, running tests shows
/Users/marcogorelli/black-dev/venv/lib/python3.8/site-packages/tomli/_parser.py:71: DeprecationWarning: Text file object support is deprecated in favor of binary file objects. Use `open("foo.toml", "rb")` to open the file in binary mode.
warnings.warn(
With black becoming stable, are there any plans to include Python APIs in the stability guarantees?
