Thanks, some minor feedback.
Also, I noticed that [x for x in *a, *b] isn't allowed. Just curious, do you know why that is?
1 messages Β· Page 32 of 1
Thanks, some minor feedback.
Also, I noticed that [x for x in *a, *b] isn't allowed. Just curious, do you know why that is?
@dense jungle I plan to merge this since there are code in the wild (as the user reported) that use this syntax, and I don't think being too permissive for black is a problem. WDYT?
I was actually going to suggest holding off until CPython made a decision on whether to revert the syntax
Ah, that is also fine. I am not too sure it will be reverted, but who knows
yeah I'd lean towards not reverting, but Pablo seems to think it's a possibility π
When a comment starts with a '#' character and after that two or more blank spaces, other tools like flake8 report
E262 inline comment should start with '# '
indicating that a comment should start with a '#' character and only one blank space.
I think it would be great if black handle this replacing two of more blank spaces after a comment start with a single blank space. Would this be a nice addition to the black formatting style?
I've been debugging why my power fix PR is changing formatting behavior when it shouldn't for over 40 minutes and I'm no where closer π¦
I know what function call in trans.py causes it but I have no idea what it is doing under the hood causing the weird behaviour
I noticed the changed cases all had a **kwargs call in them, do you know if that's part of the story?
Shouldn't according to PEP 8 here https://www.python.org/dev/peps/pep-0008/#other-recommendations something like:
hypot2 = x * x + y * y
c = (a + b) * (a - b)
should be formatted to
hypot2 = x*x + y*y
c = (a+b) * (a-b)
But black does it the other way round.
Is this intentional?
Pre-commit definitely feels faster after bumping black's version to latest
hmm that's weird since doesn't pre-commit clone black instead of using PyPI? and on top of that 22.1.0 has a stability hotfix which reduces formatting throughput by 50%
I suppose the 3.10 parsing improvements might be what is responsible for the speedup you feel since the above is only applicable for changed files thankfully.
I'm running the local black through pre-commit instead of the normal one
How is everyone doing? My name is James. This is my favorite channel. God bless, James!
So this is a setting in VS Code, just something to take note of
Maybe something to add to the Editor Integration part of the docs
This is a Python server, not a Dart one.
Technically, Black's goal is to let you forget about formatting so the ruler shouldn't really matter as Black will wrap the code appropriately on its own.
Describe the bug
Error formatting python sources in https://github.com/pytorch/fairseq
To Reproduce
Clone fairseq and run black on offending files:
fairseq $ black --version
black, 22.1.0 (compiled: yes)
fairseq $ black --check \
examples/simultaneous_translation/modules/monotonic_multihead_attention.py \
examples/speech_text_joint_to_text/criterions/text_guide_cross_entropy_acc.py \
examples/wav2vec/unsupervised/scri...
I just couldn't be arsed to apply it on Python at the time
The Python team for VS Code has been working on putting various tools we support behind LSP and breaking them out into their own extensions This work is now far enough along that we wanted to share the extension prototypes for your tool with you and see if you had any interest in owning the extension or the Python-based LSP server backing it yourself?
If you don't want to take on that res...
looks like we procrastinated for too long on that blackd PR :p /lh
how do i connect black with pycharm
do you have black[d] installed?
How can I avoid deadlock(mysql) in python multithreaded script?
Not the channel for this, try #databases
Black somehow turned this. ```py
if sys.version_info >= (3, 10):
from typing import TypeAlias
else:
from typing_extensions import TypeAlias
Into this. ```py
if sys.version_info >= (3, 10):
peAlias added in python 3.10
from typing import TypeAlias
else:
from typing_extensions import TypeAlias
π What version?
22.1.0
any custom configuration? since I can't reproduce on the playground https://black.vercel.app/?version=stable&state=_Td6WFoAAATm1rRGAgAhARYAAAB0L-Wj4ADkAJhdAD2IimZxl1N_Wlws4TilGXALX_Sht8xBkY7n5b7nLGv2KllUexZZphFWaDAHV8JqyI4IWwi73FWyLMJ6vMmioF2ixolWXt38aB1QOEmLJu_HHR1QnVdQ-dsIdxcaMTMYKgm_weX60fcPC-D9PDyeOV2ufX2FhwAWvsW1acLa7AtQL0zEBH72Awez6fJd7ZVlr-aOAN53JMIAANEeUy5esIo0AAG0AeUBAAAzdw2fscRn-wIAAAAABFla
Playground for Black, the uncompromising Python code formatter.
just changing the line-length to 79 for flake8
still not reproducible hmmm
could also be a isort thing.
Yeah, it was isort doing it.
isort version: 5.10.1 Unindented comments in an indented block seem to get cut off at the indent, which generates a syntax error. Code: import sys if True: # this will get cut off import os Output:...
consider ufmt / usort https://usort.readthedocs.io/en/stable/
it's much less likely to have these kinds of bugs: https://usort.readthedocs.io/en/stable/why.html#comparison-to-isort
Black itself is also unlikely to have this sort of bug for similar reasons
we do an AST safety check that makes sure the output is valid Python equivalent to the source
isnt there an atomic mode for isort?
looks like it, seems to just be a check for syntax errors at the end. could've helped OP, but wouldn't have helped for things like https://github.com/PyCQA/isort/issues/1507
Hi, If there is a yield statement in a file, isort alters multiline strings that contain the word "from": $ cat db.py def a(): yield f( """ select %s fr...
:D
damn.
gotta close my personal one too
seems that at least not a bot: https://github.com/felix-hilden/tekore/pull/269#issuecomment-1042921282
I got the same exact reply on my repo, so who knows maybe it is a bot after all
so they ignore the fact you need permission from all contributors to relicense (which can be covered by the CLA) but sign CLAs...
I can't explain it any other way than them being a troll
I know there are some die-hard fans of GPL but this doesn't even contain any reasoning why you would want to change license (not that it would change anything of course lol)
they responded with reasons so I'm calling "no troll" :D
Why would you switch to a more restrictive license than MIT?
You don't need permission from all contributors if you're going from more permissive license
Since you're just creating derivative work under stricter license which MIT doesn't disallow
Hence why it's permissive :D
If anyone got time, would appreciate some reviews on my PRs 
One of the things discussed in issue #144 was quote placement. Reading through the discussion, there seemed (to me, at least) to be general support for normalising this.
This does two things. For very short docstrings,
def foo():
"""
Why is this on its own line?
"""
becomes
def foo():
"""Why is this on its own line?"""
and for docstrings of more than one line, a single newline at the start and (pre-indent) end a...
^ um probably not
print ('pp')
seems like a little unnecessary, no?
seems necessary to me cheif
Does the psf/black vim plugin run a version of black sourced from the repo?
the vim plugin is running out of date black despite both my venv and system black being up to date
does something in the repo need to be updated separately for the vim plugin that got missed?
ahah, you need to separately run BlackUpgrade
(I know very few things of Python) I just had an idea: can somebody write a programm that makes student notes more eco-friendly? For instance, I have notes on a course but all the pictures and word use a lot of space and inkt. I put it in that programm and is so adjusted that nothing will be deleted, but the best usage of space and as little inkt as possible is used. Still the notes are comprehensive etc. Can somebody make that??
This isn't the channel for general Python questions. Take a read of #βο½how-to-get-help to see how you can get help with your question.
<!--
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:
pip install -U blackpip install -e .[d];Hi
Describe the style change
I think this is obvious enough that a blank line right after the function definition is against PEP-8 and against how people write functions, so better just see the examples below.
Examples in the current Black style
def func():
return "Hello"
Desired style
def func():
return "Hello"
Additional context
black-22.1.0
Python 3.10
Is your feature request related to a problem? Please describe.
It would be nice to be able to just use black src in both CI and local development.
Describe the solution you'd like
When black reformats any file, its return code would be 1 rather than 0.
Describe alternatives you've considered
Run black via pre-commit, which always returns 1 if a tool would've modified a file. This is fine for projects which use pre-commit, but (IMO, unfortunatel...
I think I'm beginning to understand why the power op comment PR is changing formatting although it's still unclear what the root cause is
β― black test2.py --check --diff --color -l 79 --fast
transforming line
running transformer: <black.linegen.rhs object at 0x7ff5f41136d0>
called trailers
calling rhs via LOOP 0 set()
rhs called
rhs called
aaaaaaaaaaaaaa = 111111111111111111111111111111111111111111111111111111111111 + (
-- a ** a
-- )
calling rhs via BEST EFFORT
rhs called
rhs called
aaaaaaaaaaaaaa = 111111111111111111111111111111111111111111111111111111111111 + (
-- a ** a
-- )
transforming line
running transformer: <black.linegen.rhs object at 0x7ff5f4dc0310>
called trailers
calling rhs via LOOP 0 set()
rhs called
<black.linegen.rhs object at 0x7ff5f4dc0310> No brackets found
running transformer: <function hug_power_op at 0x7ff5f3f1fdc0>
<function hug_power_op at 0x7ff5f3f1fdc0> No doublestar token was found in the line.
transforming line
always fun debugging like this :P
imma be honest i dont understand a thing here
Well yeah I just added a handful print calls to figure out what's going wrong in a patch I'm currently working on :)
um guys
as a joke i made my black format to line length 5
and when i try and change it back to 120 its all kind of...fucked
is there a way to force 120 for everything? o.O
like
im scarred
from __future__ import (
annotations,
)
checkout your previous commit?
im literally gonna cry
i cantttt, ive been working on this soduku for the past 4 hours
is there a formatter that forces a line length of 120?
let this be a lesson in don't run any code rewriter unless you're OK with the changes being not undoable ^^
π
unless you're using a SVC tool like git
Thanks for figuring this out! I think we should merge this despite the stability policy, but add a note to the stability policy docs about it. I can do that in a separate PR.
Thanks for writing this up and putting it under the preview style.
I'm not yet convinced we should do this, since it could be disruptive. diff-shades currently gives us results only for pyanalyze (which happens to be my code), because it runs black with preview = True. As you see, I currently use a different docstring style :)
I'd be curious to see the result on more open-source code. Could you push a change to enable the new style without preview mode, so that we can see the diff-sha...
50a8569 Isolate command line tests for notebooks from u... - freud14
@dense jungle I do have a work in progress patch to update diff-shades to force --preview, I can probably get it PRed soon
(I've just been having fun writing an "optimization" patch for mypyc and it was so engaging I ignored basically all notifications
)
sounds great, that would be good for the docstrings PR
and have fun optimizing mypyc π
the C compiler is still mad at me so I got some more work left but that doesn't sound too bad.
c26c772 Add special config verbose log case when black ... - Shivansh-007
This will let us gauge the impact of a change ahead of time.
Yup, that's why I said it was "in-progress", I still had to write the other workflow asserting stability
ah right π
I guess in that workflow we should skip projects like pyanalyze that turn on preview style
I was a little discouraged from writing it since a) it's probably a fair bit of work, and b) it involves changes to diff-shades itself since there's no way to force preview=False easily
... or yeah we could just skip them I guess
I think it's probably only pyanalyze, at least for now
hmmm, the diff-shades baseline run shouldn't be taking 8+ minutes. I wondered if I messed something up.
oh wait, I forgot I'm passing --preview ... anyway there's a crash
nice catch, I guess it gets confused about the comment in the middle of an implicit concatenation
No blockchain is involved here, we instead like to play with tree structures π
If you're wondering whether this server has a blockchain / crypto / web3 channel, the answer is no. It's been asked many times in #community-meta but we haven't seen enough interest to warrant a whole new channel.
What is this project about?
It's an auto-formatter for Python code.
Wow thatβs awesome. Is it similar to HTML one where you press control shift f (or something) and it formats it to the right indexes.
erm, it's often run from the command line, but a lot of editors have extensions to run it on save
Sweet, great work!
I've done nothing for it haha, thank all these wonderful people in purple
Thanks for creating and maintaining black it is by far my favorite code styling tool (:
On some cases black's may be incompatible with Flake8's E501 (line too long).
For example, consider code like this:
func(
long_long_long_long_long_long_long_long_long_long_long_arg=
long_long_long_long_long_class.long_long_long_long_attr
)
(less than 88 characters lines)
Black will edit it to:
f(
long_long_long_long_long_long_long_long_long...
Oh, well never mind lol
If you just put the link https://github.com/psf/black/labels/F%3A%20linetoolong, github is smart and autoformats it. There's probably another way, but that's one I know of.
Describe the style change
When an long expression contains function calls and joining operators black will choose to break the function call if the arguments exceeds the maximum line length. This can look pretty ugly. Instead, I think that black should break the outmost (least nested) parts of the expressions before inner parts of the expression.
Examples in the current Black style
def parse_assign_stmt(self) -> Optional[ast.AssignStmt]:
if isinstan...
A @client.event for Discord.Py, It's made to shut the who asked kids up, The possibility for some to bypass it is %38...! - GitHub - SamTheNoob69/whoaskedfilter: A @client.event for Discord...
who likes my idea
Hi everyone, i want to ask u if anyone build befor a recommender system using ML ?
@civic plume, @versed trout this is not a proper channel for this. Read the channel topic.
does anyone wanna play minecraft with me
!ot - A little off-topic for this channel :) perhaps ask in a OT channel?
Off-topic channel: #ot2-the-original-pubsta
Please read our off-topic etiquette before participating in conversations.
fine
Sup, I'm working on a legacy python project and naturally it uses every python code style under the sun. I'm trying to introduce black in order to standardize it but there is quite a bit of resistance from the old devs. Chiefly they don't like:
""" Foo """ becomes """Foo"""foo(very_long_line) becomes foo(\n\tvery_long_line\n)'this string' becomes "this string"can I change these settings in black? From the docs it seems that fiddlin with small stuff like this is not really supported, am I out of luck/need to look to another automatic code formatter?
jikes, sorry for the formatting
Ok, thanks for the response π
Good morning my name is Raj Mukherjee and I am new to this community. I am pursuing my B.Tech degree from Srm University in artificial intelligence and I am working on python for quite a few years and I have also started working on Data Science, Artificial Intelligence and Machine Learning so as per my interest I would like help and contribute something to this community
You should checkout the github repo for this project
Ok i will check it out
wat is CI doing ...
I wonder if this is just that edge case where the fact the PR isn't tested with main merged in
Race between #2889 and another PR.
Have we documented how there's two classes of formatting changes? We should clarify we'll try to limit non-preview style changes to bugfixes which don't change anything for already formatted codebases.
6cfb518 separate CHANGELOG section for preview style (#... - JelleZijlstra
If a vim/neovim user wishes to suppress loading the vim plugin by setting g:load_black in their VIMRC (for me, Arch linux automatically adds the plugin to Neovim's RTP, even though I'm not using it), the current location of the test comes [after a call to has('python3')](https://github.com/psf/black/blob/9b161072c13c0ec32c9ca9bd48fad17f781a56d4/plugin/black.vim#L18...
Is this related to a problem? Please describe.
Link on the PyPi home page for black's readme is broken: https://black.readthedocs.io/en/stable/the_black_code_style/current_style.html#pragmatism
Describe the solution you'd like
Unbroken link
Describe alternatives you've considered
N/A
Additional context
N/A
hmmm I don't really like this furo update
concretely I feel like the headings are now too bold, I could see how they could've seemed too dim previously but this feels like the other side of the spectrum π
Also, it's not that clear IMO that 22.1.0 is a higher heading than Highlights
https://black.readthedocs.io/en/latest/faq.html feels very shout-y now
honestly, I always found difference between different levels of headings in furo to be hard to notice sometimes
I saw pycln (which is a formatter for finding and removing unused import statements) a good addition to the current pre-commit hooks which I believe would ensure a high code quality standard besides black itself.
Also, I've two things to mention:
pycln.black contribution.Anyway, feel free to ask any questions and/or reject/close this PR if you don't want to add more QA tools to black's pre-commit hooks.
...
I want to customize black by cmd
I don't know why they switched to furo
I've found furo beautiful but also not beautiful
Describe the style change
The following code:
def foo(a)
print(a)
foo(a=([1, 2, 3]))
Should be changed into:
def foo(a)
print(a)
foo(a=[1, 2, 3])
Examples in the current Black style
As for now, the example above is not changed.
Desired style
When circular brackets are not used to break up command parameters into different lines, it should be removed entirely
Additional context
I use python 3.9 on Windo...
the windows docs build is real slow
Seems to be a one off
HiImManh#2550
everybody add this account to the dead toxinloght
beacause he make a lot of thing that make problem
A few thoughts:
Given the initial negative feedback I'm inclined to reject the PR from a birds-eye view.
I haven't actually looked at the PR in detail yet.
what negative feedback? the downarrow emoji?
I think I mostly like it now, it really isn't much worse than the docstring processing we already do
I'm mostly scared of the backlash π
Yeah.. and I'm not particularly fond adding another option for this. I suspect there isn't enough consensus to make this feasible longterm.
what we choose creates the consensus for how Python is formatted
I'm mostly not joking
Yeah although I'm acutely aware of the issues that will get opened when there's any room for disagreement in style. I guess that's unavoidable though regardless if we change the style or not.
just means we get to close more
I have a problem when tf.string.to_number make operation , I RESOLVED the issue.
This is because the last line of the conlleval train_data.txt it's blank , if we want to comprove this we can make:
pandas.DataFrame.from_dict(conll_data["train"]) and we can see the last row --> row NΒΊ 14041 have lists without nothing .
SOLUTION :
Go to data folder , open train_data.txt and delete the last row , it's work fine for me
The reason they downvoted it was they use a a doc string format like """|coro
something something
"""" and this expand that a lot more
Do reckon adding an option for docstring processing or more broadly AST safety would be better?
isn't the del parens thing the only other AST-unsafe thing we do? I don't really want an option for that
psf/black#212 would be another one, but I'm totally ok with just the docstring thing
but that is also another one where an option for it would be odd
at least with docstrings it makes some sense
yes, I don't think an option for that would be necessary, unless we can really find a case where it makes a difference in practice
Docstrings are actually visible at runtime and there are lots of tools that parse them, so it's more plausible that reformatting them will break something
What are you all talking about
Fixes #2569: error on windows directory junctions
MD5 is unavailable on systems with active FIPS (Federal Information Processing Standards) mode, such as RHEL or CentOS. That makes black crash when run on such systems:
python -m black --config pyproject.toml --check pcs/ pcs_test/
Traceback (most recent call last):
File "/usr/lib64/python3.6/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
File "/usr/lib64/python3.6/runpy.py", line 85, in _run_code
exec(code, run_globals)
File...
Thanks! This does need a changelog because it fixes a user-visible issue.
we should probably do a new release soon
Yeah, I would've brought it up sooner but .. I'm still the blocker. The mypyc build workflow is still not up. Given my terrible mental state it would probably be better to just do it manually again, maybe even asynchronously for this next release.
Thanks for holding down the fort while I've been checked out by the way, it's nice not having to stare at unreplied-to emails.
no worries! take care of yourself
Yeah, personal life first mate. Can we/I help with any of the wheel build flow?
why does black turn
SomeClass(
param=(
"Lorem ipsum dolor sit amet"
"I forgot the other parts"
)
)
into
SomeClass(
param=(
"Lorem ipsum dolor sit amet" "I forgot the other parts"
)
)
because we haven't turned --experimental-string-processing on by default yet π
so i can just turn that on and it will leave the string alone?
it doesn't, it joins the two together into one string
yes, if it fits in one line
default line length is 88
is black first or third party?
first to us π
What does that even mean?
we're not affiliated with the PSF or CPython project other than the former giving us some administrative help
We aren't the official formatter for Python if that's what you were asking
There's no such thing
anyone using black in neovim here?
I have the plugin working, but formatting using = still formats differently
Today's new furo release should fix the heading typography issues -- I'mma test it locally and then merge
Yeah it's a lot better -- still not perfect IMO, but it's actually readable
Has been documented in https://github.com/python/cpython/pull/31481. Thanks for fixing this Batuhan!
@bright glacier if you have time, do you know how I could get the anchor links in https://github.com/psf/black/pull/2839 to work?
I've been procrastinating that for a while now π
I've been procrastinating on documentation changes for even longer π
Describe the bug
The = specifier was added to f-strings in Python 3.8, but Black does not yet distinguish it from any other f-string, and therefore detects the version as 3.6+. This leads to missed formatting opportunities, and sometimes problems in downstream projects since this is invalid syntax under earlier versions. (e.g. https://github.com/Zac-HD/shed/issues/31, prompting this issue)
To Reproduce
from black import detect_target_versions, parsing
code =...
(I'm sorry, I open the worst issues...)
can confirm, https://github.com/psf/black/issues/1557
and thanks for reporting this!
Looking at https://github.com/psf/black/issues?q=is%3Aissue+author%3AZac-HD+-label%3A"R%3A+duplicate"+-label%3A"T%3A+documentation", I reckon most of these are pretty gnarly...
https://github.com/psf/black/issues/1012 is pretty nasty π
man, I remember reading this great source on sphinx refs, just gotta find it
I feel like https://github.com/psf/black/runs/4999187973?check_suite_focus=true is a bug the more I look into it
Yes. _Black_ is strictly about formatting, nothing else. Black strives to ensure that
after formatting the AST is
[checked](the_black_code_style/current_style.md#ast-before-and-after-formatting) with
limited special cases where the code is allowed to differ. If issues are found, an error
is raised and the file is left untouched. Magical comments that influence linters and
other tools, such as `# noqa`, may be moved by _Black_. See below for more details.
it works here?
I wonder if we could just sidestep the issue by folding usage and configuration into a single document
Anyway I'mma see if I can create a reproducer because I have no idea what's wrong here
!remind 3H documentation is hard
Your reminder will arrive on <t:1646531537:F>!
Here's your reminder: documentation is hard
[Jump back to when you created the reminder](#black-formatter message)
!remind 100Y 
Your reminder will arrive on <t:4802232113:F>!
0s is not a valid duration string.
!remind delete 4187
There does not seem to be anything matching your query.
!remind 1s Oo
Your reminder will arrive on <t:1646558624:F>!
Here's your reminder: Oo
[Jump back to when you created the reminder](#black-formatter message)
Your reminder will arrive on <t:1646558640:F>!
@mint barn
Here's your reminder: hello
[Jump back to when you created the reminder](#black-formatter message)
please don't spam this channel (or any channel for that matter)
oh
#bot-commands exists for a reason @mint barn ^^
Describe the style change
Black ignores line length limit for dictionaries that have long key / value values, but could be split into 2 lines.
Examples in the current Black style
my_dict = {
"my very long key that cannot be shortened": "my very long value that unfortunately also cannot be shortened :(",
}
Desired style
my_dict = {
"my very long key that cannot be shortened":
"my very long value that unfortunately a...
did someone face this issue before?
??
first pip doesn't work for
mac@MBP-de-mac site-packages % pip --version
zsh: command not found: pip
I did pip3 and it worked for me as you can see
mac@MBP-de-mac site-packages % pip3 --version
pip 22.0.4 from /Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/pip (python 3.10)
when i do pip install black doesn't work for
mac@MBP-de-mac site-packages % pip install black
zsh: command not found: pip
With this one i did pip3 also as you can see
mac@MBP-...
Do python3.10 -m black .
you may need to activate a virtualenv if you have it installed in one.
first pip doesn't work for
mac@MBP-de-mac site-packages % pip --version
zsh: command not found: pip
I did pip3 and it worked for me as you can see
mac@MBP-de-mac site-packages % pip3 --version
pip 22.0.4 from /Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/pip (python 3.10)
when i do pip install black doesn't work for
mac@MBP-de-mac site-packages % pip install black
zsh: command not found: pip
With this one i did pip3 also as you can see
mac@MBP-de-mac site-packages % pip3 install black
Requirement already satisfied: black in /Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages (22.1.0)
Requirement already satisfied: mypy-extensions>=0.4.3 in /Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages (from black) (0.4.3)
Requirement already satisfied: pathspec>=0.9.0 in /Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages (from black) (0.9.0)
Requirement already satisfied: click>=8.0.0 in /Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages (from black) (8.0.4)
Requirement already satisfied: tomli>=1.1.0 in /Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages (from black) (2.0.1)
Requirement already satisfied: platformdirs>=2 in /Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages (from black) (2.5.1)
But I can't work with black i don't know why
mac@MBP-de-mac web3_py_simple_storage % black .
zsh: command not found: black
Please can someone help me
@proper rampart
i did it but the black option doesn't work
Wdym?
let me show a example
as you can see here
this is the problem that i face
Oh idk what you'd need to do to fix it in vsc
Describe the style change
Given the following docstring, black shouldn't insert a leading space.
""""Cookie eaters" are the set of people that eat cookies."""
Examples in the current Black style
""" "Cookie eaters" are the set of people that eat cookies."""
Desired style
""""Cookie eaters" are the set of people that eat cookies."""
(Which is how docformatter leaves it)
Additional context
Nope, it's all unofficial still. We want to define one eventually, but it's been low priority for time being.
ah alr
I am still doing my formatter function thing
Can't wait to do it officailly π
HEY
Is CPython 3.11-dev available on GHA, if so we should add that (in a separate PR)
Is your feature request related to a problem? Please describe.
In https://github.com/pandas-dev/pandas/pull/46279 someone wants to make the pandas codebase adhere to PEP484, so they add None return annotations to some __init__ methods. This is a bummer that this is manual. It would be nice if this could be included in pandas's code checks in CI, so the entire code base was consistent.
Describe the solution you'd like
It would be nice if black added this annotation automat...
Ok my exams are almost over, one remaining, will resume work on my PRs from Friday 
And maybe open some more ;)
!remind push diff-shades changes..?
push is not a valid duration string.
!remind new 2H push diff-shades changes..?
Your reminder will arrive on <t:1646875698:F>!
Here's your reminder: push diff-shades changes..?
[Jump back to when you created the reminder](#black-formatter message)
@main flume This channel is for discussions about the Black formatter - please try out commands in #bot-commands next time
@hallow bane Do not spam the eval command in random channels. Please see #bot-commands for that
Please observe the channel topic
K
!remind 50d can we test CPython 3.11-dev on GHA yet?
Your reminder will arrive on <t:1651276650:F>!
that's roughly when the first beta should be available, currently yarl and aiohttp fail to compile due to a header file being deleted / moved upstream
Hi
@dense jungle psf/black#2525 should be ready for review now, sorry for the delay
So is psf/black#2770
(all are ready)
ok will take a look in the next few days
Describe the style change
Align quotation marks for multi-line string breaks (using --preview) if the resulting strings are a mixture of f-strings and normal strings.
Examples in the current Black style
Before black:
def f():
stuff, things = 1, 2
long_string = f'When you create an f-string that contains so much {stuff} it has to be split over multiple lines, some splits might not "contain" interpolation in them. That makes the quote {things} not alig...
Currently working on rewriting the diff-shades integration to add a job that forces the stable style and fails on changes.
Unfortunately it's a bit of a mess since it will require changes on diff-shades' end ... and the CI is still failing due to that ineffective monkeypatch.
Also this adds parallelization AND a pre-configuration job to the workflow so I think I'm going to be the only one capable of maintaining this for the forseeable future...
I guess more documentation that details how it works couldn't hurt.
I realize we haven't used the workflow dispatch feature of the workflow and it continues to be a thorn when adding features since often it doesn't need the same level of automation as pushes and PRs. It might be worth removing since I can't really think of a situation we'd use it anyway.
And even if it was useful, it's 100% feasible to do the same kind of thing locally, it's just more effort which is probably fine for such a rare usecase. It was easy to implement within the original requirements, but it's not worth it anymore.
Phew, I wasn't too indecisive this time.
good call!
the only minor issue is that the PRs we do make that stabilizes any preview formatting changes will be red thanks to diff-shades but that seems fine
at most it'll be a yearly occurrence done by a maintainer who should know what's up
have a label to decide whether we want to run preview diff-shdaes or non preview?
the planned design runs both, one to preview changes and one to fail on stable changes
and I don't think it's worth keeping a label for these one off events
yeah, I guessed that, but you said it would be red for preview formatting changes, so we can decide on which of the diff to follow from that? if you get what i mean
oh ok, i read that wrong. my bad
the only minor issue is that the PRs we do make that stabilizes any preview formatting changes will be red thanks to diff-shades but that seems fine
no worries
ok, are we running preview formatting or just the stable formatting on black?
i see the tests are failing when i include preview formatting changes in the source
I changed it recently to format Black itself with preview style
even the tests?
like the test to check if source is formatted
ok nope
should i include that in 2770 or make a new one, i belive thats something we want as we are formatting with preview style
otherwise the tests would be fialing
dunno why that doesn't happen now with main branch 
oh hmm I wonder the test isolation recently added is overriding the preview=True in pyproject.toml
uhhh which test isolation? could you point to the commit
like adding --config=tests/empty.toml everywhere
ah, yeah that's it
Hmm actually I doubt it since the test checks per file and that would skip the configuration file anyway
I'm AFK tho so I can't check
ok, i don't think we are adding empty config for the test_source_is_formated
can't see anything in the related code
tests/test_format.py line 154
check_file(str(path), DEFAULT_MODE, data=False)```
there ^
ah default mode, that'd do it
Right, one more test is failing of test_piping in BlackTestCase
If the ``.ipynb`` originally had a trailing newline, it'll be preserved.
"""
- trailing_newline = (src_contents[-1] == "\n")
+ trailing_newline = src_contents[-1] == "\n"
modified = False
nb = json.loads(src_contents)
none of the tests are adding --preview
should i just add them by default to BlackRunner or add them spearately to each?
only the tests that test black's own formatting. normal unit tests should run in stable mode
even expressions.diff test?
why not?
In the feature enum, if want to add anew feature for the detection purpose, what number will i give? And what are these numbers? Can't really understand them from just looking at them
I think they're just random
ok, so i will just choose the next number for F_STRING_EQEQUAL_DEBUGGING feature, couldn't find a better name for f"{x=}"
I think "debug f-strings" is the usual term, so I'd suggest DEBUG_F_STRING
ok, that's what i had earlier, found the feature names a bit more explicit, so included the operator name
Also, for the detection, I am just using "=" in code_inside_braces_of_string", or there are edge cases to this which i am not aware of?
that seems wrong it would catch, f"{x == y}"
from https://docs.python.org/3/reference/lexical_analysis.html#formatted-string-literals seems like it should be at the very end or before ! or :
oh oi forgot about those, yep i think regex would be a good fit then
but wouldn't the parsing fail if we have a hanging =?
we can only parse x= in f"{x=]" since we don't have f-string support yet
or we check if the first char isn't ' or "? since if it is not and they are included after a var, then it is invalid syntax
not sure what you mean, f"{x+'=:'}" is also valid
:=
you can in fact use walrus inside an f-string ```>>> f"{(x:=3)}"
'3'
x
3
(please don't)
oh wow i didn't know tht
!file 18H file some visual output suggestions to rich-click to add more newlines
Thanks to discord.py, sending local files as embed images is simple. You have to create an instance of discord.File class:
# When you know the file exact path, you can pass it.
file = discord.File("/this/is/path/to/my/file.png", filename="file.png")
# When you have the file-like object, then you can pass this instead path.
with open("/this/is/path/to/my/file.png", "rb") as f:
file = discord.File(f)
When using the file-like object, you have to open it in rb mode. Also, in this case, passing filename to it is not necessary.
Please note that filename can't contain underscores. This is a Discord limitation.
discord.Embed instances have a set_image method which can be used to set an attachment as an image:
embed = discord.Embed()
# Set other fields
embed.set_image(url="attachment://file.png") # Filename here must be exactly same as attachment filename.
After this, you can send an embed with an attachment to Discord:
await channel.send(file=file, embed=embed)
This example uses discord.TextChannel for sending, but any instance of discord.abc.Messageable can be used for sending.
ah fantastic
!remind new 18H file some visual output suggestions to rich-click to add more newlines
Your reminder will arrive on <t:1647204556:F>!
It's very nice and I want to add it to diff-shades but it's a young project and has a lot of rough edges imo
also, yeah the lack of typing support is a hard no (fixed on main apparently tho)
Closes #2067
Closes #2828
aww, I looked at this diff, noticed Preview.hex_codes_in_unicode_sequences in self.mode and thought I somehow missed that you can actually enable a single preview feature rather than go all in
Well not from the command line though
it's intended just for converting specific features to stable
src/black/mode.py line 157
def __contains__(self, feature: Preview) -> bool:```
I think the reason it's done like this is due to experimental string processing flag but anyhow, I know it's not possible from cli that's why I was sad lol
"aww" was for sad
yeah ESP is a special case
once esp is merged in? would this still remain or preview would be handled as a single config?
will still remain, although the 2 lines specifically for ESP will be deleted of course
would be nice if the preview flag was granular, not gonna lie
experimental string processing is a bit much for me while it's still experimental but a feature like the one above would be nice to enable sooner
Sorry, it won't be π
too many different possibilities of people setting these flags in I guess
Describe the bug
A comment #fmt:skip with no internal space causes INTERNAL ERROR: Black produced different code on the second pass of the formatter
Also the same code, if run with --fast creates incorrectly formatted code with multiple copies of the comment on the next line.
To Reproduce
For example, take this code:
import re
line = "some dummy data"
log_search = re.search('CLOCK:\s*(\[.*\])--(\[.*\])\s*=>\s*(\d*:\d*)', line) #fmt:skip
And...
I can't reproduce it in a windows terminal -- I bet rich changed something on windows
could also be a windows-specific rich bug, it seems it only occurs when a non-interactive terminal is detected
rich 12.0.0 dropped colorama
though it should support legacy windows console on its own now
somehow printing is fully broken on the new terminal too, this makes no sense
I just love windows, it's totally not the source of many bugs over the years :) /s
(notepad++ may or may not be frozen right now thanks to windows update)
e
yeaa according to the test output it's straight up not printing anything to stdout in a subprocess :/
does it only happen in CI or can you repro it locally too
locally too if I'm not using a terminal directly
strange
what about when you change command prompt's settings to use legacy console mode
I feel like it must be my fault somewhere since this would be a very bad bug but I have no idea where to start debugging lol
what even ...
i-
@lament crow have you seen something like this?
yup π
you got my curiosity up so I'm gonna clone diff shades lol
This makes no sense though since running a rich application through a subprocess with stdout attached to a pipe should be tested on windows
and even if this somehow wasn't tested in their CI, it should've been reported by now!!! but I can't find an issue
I can't repro
fun fun fun
hmm, try uninstalling colorama
still broken
(venv) PS R:\Programming\diff-shades> pip freeze
atomicwrites==1.4.0
attrs==21.4.0
black==22.1.0
click==8.0.4
commonmark==0.9.1
coverage==6.3.2
-e git+https://github.com/ichard26/diff-shades.git@d33bf5ae691f9e702e99a148ba521d207b6e8fb9#egg=diff_shades
iniconfig==1.1.1
mypy-extensions==0.4.3
packaging==21.3
pathspec==0.9.0
platformdirs==2.5.1
pluggy==1.0.0
py==1.11.0
Pygments==2.11.2
pyparsing==3.0.7
pytest==7.1.0
pytest-cov==3.0.0
rich==12.0.0
tomli==2.0.1
typing_extensions==4.1.1
I guess isolated virtualenv time?
hmm?
I'm in a virtualenv, it's diff-shades' tho
I don't have 12 there lol
I'm in venv too
but subprocess.run(["python", ... runs the global python
apparently...
but how
okay, now I can repro
I have no clue why it's using wrong python though,
like, shouldn't subprocess use PATH to determine this...
well, whatever >.<
wait how?
by actually using right python by passing sys.executable
!code
my global env's rich is not 12
ah lol
I just didn't realise it's using that
I don't have rich in my global env AFAIK
I stop using windows day to day by the time I learned to not install everything in the global env
I mean, the thing I have in global env work fine :)
then apt would not work
totally have them all installed as admin so that pip can write to C:\Python38\lib\site-packages
so I went to another machine running Linux and copied some of the files
apt works again
I mean on my ubuntu install I gave myself ownership of some files under /opt to make my python installations work lol
Probably worth a bug report because I'm running out of ideas (or I guess we could ping will here, but that sounds rude :) )
unless you have more ideas on how to debug these weird windows issues :p
it assumes that a non-terminal is legacy console
and therefore uses Windows APIs to write to console rather than use stdout
ye, it only has special handling for first stream
I assume the Windows APIs work that way
I've reached the limit of my rich and windows knowledge so I'm just listening :)
I mean, you should report it to rich
I was just waiting on you whether you'd all of sudden discover why :)
I will do so though.
I'm pretty sure it's because it can't use WriteConsole API (the one that's used for legacy console printing) when it's piped because output from WriteConsole is not capturable
but I haven't used those APIs so I can't say that for certain
WriteConsole fails if it is used with a standard handle that is redirected to a file
well
(I have never written C code on windows)
I guess I could just read documentation then
well that's a slight lie, I have like three years ago? but I've forgotten all of it and anyway I have never worked with windll or the windows APIs
I wrote a bit in university but like, not much...
well, not much in terms of the amount of different API functions that I used
because winapi is pretty extensive π
certainly never worked with console apis
import subprocess
import sys
code = """\
import sys
from rich.console import Console
console = Console(file=sys.stdout)
console.print("spam")
"""
err_code = code.replace("sys.stdout", "sys.stderr")
cmd = [sys.executable, "-"]
print("[capture_output=True via sys.stdout]")
proc = subprocess.run(cmd, input=code, capture_output=True, encoding="utf-8")
print(f"{proc.stdout=} {proc.stderr=}")
print("[capture_output=True via sys.stderr]")
proc = subprocess.run(cmd, input=err_code, capture_output=True, encoding="utf-8")
print(f"{proc.stdout=} {proc.stderr=}")
print("[capture_output=False via sys.stdout]")
proc = subprocess.run(cmd, input=code, capture_output=False, encoding="utf-8")
reproducer made
seems fine
I would include this excerpt from WriteConsole's documentation:
WriteConsole fails if it is used with a standard handle that is redirected to a file. If an application processes multilingual output that can be redirected, determine whether the output handle is a console handle (one method is to call the GetConsoleMode function and check whether it succeeds). If the handle is a console handle, call WriteConsole. If the handle is not a console handle, the output is redirected and you should call WriteFile to perform the I/O.
https://docs.microsoft.com/en-us/windows/console/writeconsole
Anyway I guess I'll just ban rich==12.0.0 on windows. I need to get diff-shades functional in the time I wait for a response.
Here's your reminder: file some visual output suggestions to rich-click to add more newlines
[Jump back to when you created the reminder](#black-formatter message)
!e
This is probably the wrong channel, no?
Black exempts single-element tuple literals from the usual handling of magic trailing commas: (1,) will not have a newline added (as would happen for lists, sets, etc.).
I'd like to be able to write type annotations for a tuple-of-one-element in the same way, so that I can write either tuple[int,] or tuple[int, ...] without looking quite so much like list[int]. However, Black's current add-a-newline code style makes this pattern unattractive, so I'm unlikely to write a linter ...
I got annoyed at the way list[int] tempts people to write tuple[int] for their type annotations, and decided to write a linter which forces tuple[int,] if you meant the latter (instead of tuple[int, ...] for variable-length).
Except that Black makes that too ugly to expect much adoption, so...
closes #2588
Black version: 22.1.0
Suppose I have a deeply nested dict-like object:
data = {
"long_key_name_0": {
"long_key_name_1": {
"long_key_name_2": {
"long_key_name_3": {
"long_key_name_4": {
"long_key_name_5": {
"long_key_name_6": {
"long_key_name_7": {
"long_key_name_8": {"long_key_name_9": {}...
Describe the bug
Black removes redundant parenthesis in most contexts, but this does not apply to the with statement yet.
To Reproduce
Playground link
if (open("bla.txt")):
pass
with (open("bla.txt")):...
Thanks for the PR once again! A comment and some nits below π Let's discuss.
I promise to get diff-shades ready for post-stable use soon! I'm just following up on the rich bug and then I need to test out the integration patch ^^
OK so bug.py is working correctly on master but diff-shades' test suite is still failing
I guess it's something specific to Console(record=True) now .... 
@lament crow what the hell
import subprocess
import sys
code = """\
import sys
from rich.console import Console
console = Console(file=sys.stdout, record=True)
console.print("spam")
print(f'recorded: {console.export_text()}')
"""
err_code = code.replace("sys.stdout", "sys.stderr")
cmd = [sys.executable, "-"]
print("[capture_output=True via sys.stdout]")
proc = subprocess.run(cmd, input=code, capture_output=True, encoding="utf-8")
print(f"{proc.stdout=} {proc.stderr=}")
print("[capture_output=True via sys.stderr]")
proc = subprocess.run(cmd, input=err_code, capture_output=True, encoding="utf-8")
print(f"{proc.stdout=} {proc.stderr=}")
print("[capture_output=False via sys.stdout]")
proc = subprocess.run(cmd, input=code, capture_output=False, encoding="utf-8")
(venv) PS R:\Programming\diff-shades> python .\bug_record.py
[capture_output=True via sys.stdout]
proc.stdout='spam\n' proc.stderr="Exception ignored in: <_io.TextIOWrapper name='<stdout>' mode='w' encoding='cp1252'>\nOSError: [Errno 9] Bad file descriptor\n"
[capture_output=True via sys.stderr]
proc.stdout='recorded: spam\n\n' proc.stderr='spam\n'
[capture_output=False via sys.stdout]
spam
recorded: spam
and now export_text is just plain broken
(venv) PS R:\Programming\diff-shades> python .\bug_record.py
[capture_output=True via sys.stdout]
proc.stdout='spam\nrecorded: spam\n\n' proc.stderr=''
[capture_output=True via sys.stderr]
proc.stdout='recorded: spam\n\n' proc.stderr='spam\n'
[capture_output=False via sys.stdout]
spam
recorded: spam
running with rich==11.2.0 works as expected
report that on the issue
windows. just wonderful
minor correction, the recording stuff works but printing is still acting up
If I switch to using console.print instead of the built in print with 12.0.0 I get this weirdness
(venv) PS R:\Programming\diff-shades> python .\bug_record.py
[capture_output=True via sys.stdout]
proc.stdout='spam\n' proc.stderr='Traceback (most recent call last):\n File "<stdin>", line 6, in <module>\n File "R:\\Programming\\diff-shades\\venv\\lib\\site-packages\\rich\\console.py", line 1642, in print\n self._buffer.extend(new_segments)\n File "R:\\Programming\\diff-shades\\venv\\lib\\site-packages\\rich\\console.py", line 841, in __exit__\n self._exit_buffer()\n File "R:\\Programming\\diff-shades\\venv\\lib\\site-packages\\rich\\console.py", line 799, in _exit_buffer\n self._check_buffer()\n File "R:\\Programming\\diff-shades\\venv\\lib\\site-packages\\rich\\console.py", line 1935, in _check_buffer\n with open(file_no, "w") as output_file:\nOSError: [WinError 6] The handle is invalid\n'
[capture_output=True via sys.stderr]
proc.stdout='' proc.stderr='spam\nrecorded: spam\n\n'
[capture_output=False via sys.stdout]
spam
recorded: spam
although that doesn't explain why the test suite is failing, I feel like I'm missing something
OK actually stuff is still pretty broken
recording, using the built print, and even printing again with console's print are all failing in different ways with STDOUT
OK they've been reported.
hmm, sqlalchemy is still failing, unfortunately diff-shades doesn't let you just ignore errors for a project or file.
the best interim option would be not fail the workflow on file failures
Hey, I'm looking for volunteers who could help with the script benchmarks.
Just download this repository and inside from the terminal position type
python3 main.py "test" "test" 130 90
I need this data to make a table comparing password cracking times for a specific processor.
This is probably the wrong channel, no? Not sure how this is related to the psf/black oss project ^^
so close! but I need to rewrite the log file name or else this confusing diff difference will occur >.<
It's kinda scary how much time this one task has taken me, but this integration is probably one of more helpful improvements to developer experience so it's worth it π
so I stopped failing the workflow if the baseline revision has failing files and also added --check-allow so we can specifically ignore certain already known issues (for the target revision)
It's been a while since I last ran pre-commit autoupdate.
https://github.com/RandyMcMillan/x20bf/runs/5547164070?check_suite_focus=true
error: cannot format /home/runner/work/x20bf/x20bf/x20bf/depends/git/test/performance/test_odb.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: /tmp/blk__z8nbt2n.log
INFO:blib2to3.pgen2.driver:Generating grammar tables from /home/jdjg/JDBot/JDBot/lib/python3.8/site-packages/blib2to3/Grammar.txt
INFO:blib2to3.pgen2.driver:Writing grammar tables to /home/jdjg/.cache/black/21.12b0/Grammar3.8.10.final.0.pickle
INFO:blib2to3.pgen2.driver:Writing failed: [Errno 2] No such file or directory: '/home/jdjg/.cache/black/21.12b0/tmpzys_y126'
INFO:blib2to3.pgen2.driver:Generating grammar tables from /home/jdjg/JDBot/JDBot/lib/python3.8/site-packages/blib2to3/PatternGrammar.txt
INFO:blib2to3.pgen2.driver:Writing grammar tables to /home/jdjg/.cache/black/21.12b0/PatternGrammar3.8.10.final.0.pickle
so I installed black into venv
I am not sure why this is an issue now
didn't have this issue until yesterday
Version: 21.12b0
You can honestly ignore those, it may say error but black can recover from that one
@neon loom I copied black-primer to https://github.com/ichard26/black-primer. Do you want me to transfer it to you?
Ready to make it an optional install in case someone uses it?
Well to point people there?
Iβm cool to just be added as a moderator if you want a second person.
Iβll take this and move it to cooperlees/black-primer after the release and if people want it they can install it from there β¦
I didn't misread this, did I?
Letβs share on the Readme that itβs unsupported and only there for legacy use cases - fork away.
Yeah we can do that or im happy if itβs easier to just use yours - I donβt care
What ever is easier
well my plan was to
I was just trying to save you some effort by making the repo myself and then transferring it to you as you originally planned / stated
Cheers
I just wanted it available in the low chance someone is like what I use primer β¦ etc etc
Cool, I had some free time and decided to do part of the work for ya :)
glad to hear I didn't misread and wasted an hour 
can u help me?
can u help me?
I've already told you before, but no there's web3 stuff going on here.
Seriously, please stop pinging a bunch of random people for help. Or at least provide more context to make the ping worth it.
Sorry - the transfer expires very quick. I thought it would wait till the am, seems not
Enjoy your retirement at https://github.com/cooperlees/black-primer
Resolves #2821 and closes https://github.com/psf/black/issues/2193.
I'm actually a bit sad π₯²
thanks, I was too lazy to find the file myself π
Suspect regression. Using v 4.0.1 (Gentoo X86_64). Having just installed black (v22.1.0), reformatting produced multiple W503 messages. Attempted to utilize extended-ignore and reloaded/rescanned project. Warnings persisted. I ensured no W503/W504 ignores were present in code or configuration. Only after adding explicitly W503 to extended-ignore would flake8 be satisfied.
_Originally posted by @scottfurry in https://github.com/psf/black/issues/1661#issuecomment-1048462407_
Closes #2921. Aims to remove redundant parentheses from with statements:

I currently have one failing test tests/data/parenthesized_context_managers.py since this code now removes unnecessary parentheses around one-line with statements, so...
If someone else could walk through this person through the tests and preview that'd be great ^^
on it
Hi
Walk through what
this
Good bye old warrior. You helped bring back black development to life!
a57ab32 Farewell black-primer, it was nice knowing you ... - ichard26
I got stuck with this error can someone please help me out
Is your feature request related to a problem? Please describe.
Include all sources of gitignore patterns.
I have user and host specific ignore rules in ~/$USER/.gitignore that Black is unaware of.
>>> cat ~/.gitignore
*.swp
*.swo
.DS_Store
.ropeproject
.mypy_cache
.ccls-cache
.clangd
And just started adding black into my workflow at a project root level instead of an individual call to a specific file.
So the file finding process included python files in the...
https://github.com/psf/black/runs/5563343510?check_suite_focus=true#step:9:35 what would be the best way to go around this?
wow that's a weird error
yeah :(, mypy can be troubelsome sometimes
commented on the PR
you successfully tricked me into reviewing the rest of the PR too π
ty :D
just wanted to say we use black in our class and it does make the code much easier to read
thank you

Currently, the imports exist in any random order as added by the developers (see below), which sometimes makes it difficult to look through them in search of something. Furthermore, it is not very pretty or easy to read.
https://github.com/psf/black/blob/086ae68076de570b0cb1881a3c3b9da592b46ee0/src/black/__init__.py#L52-L59
https://github.com/psf/black/blob/086ae68076de570b0cb1881a3c3b9da592b46ee0/src/black/__init__.py#L6-L11
This is where isort comes in, isort, unlike black is a...
Felix, finally opened the issue :D
mint ππΏ
Closes #2914. I've confirmed that C0330 & C0326 checks no longer exist in pylint, therefore we can remove them from the config docs.
hi . intermediate python coder here. i am looking to upskill my coding level, introduce type hinting into my code, use linters etc. i wanted to know what is the difference between black and the linters suggested in my vs code e.g. mypy, pylint, flake, etc.. and what is autopep8... do these all work to conform the code style with PEPs? so what is the difference between them?
they basically work at different levels. black and autopep8 are autoformatters, they do things like split up long lines and add whitespace
mypy is a type checker. it looks at type annotations in your code and tells you when you do something like 1 + "x" that breaks the type system
why are there so many linters? do they all do the same job? and which one is the best?
flake8 and pylint are linters, which are kind of in between the two. they find (and sometimes fix) various mistakes or risky bits in your code
this might seem like a dumb question but why not combine the functionality of autoformatters and linters into one package?
black + flake8+pylint all into one?
they do very different things internally. you could make a tool that wraps a bunch of them but not sure how useful that would be
in particular, autoformatters format code in place and linters and type checkers produce lists of errors, so the output format is very different
Is this related to a problem? Please describe.
Describe the solution you'd like
Describe alternatives you've considered
Additional context
nice to see in https://github.com/PyCQA/pylint/pull/3577 that pylint is moving to get rid of checks that duplicate what Black does
(and thanks @tired shard and the PR author for digging up those links π )
Btw ichard, would love to see a review on psf/black#2525, seems super close to merge :D
yes GH is having some issues today
ah yep webhook performance looks degraded
Welcome to GitHub's home for real-time and historical data on system performance.
new pfp π is that you?
a bit different looking than the previous one
what is pfp?
profile pic
nice beard and hat π
"isort, unlike black is a fantastic ... tool" :^)
how do i configure black in Pipfile, like i can in pyproject.toml
i tried [black] and [tool.black]
that's not supported
:( why not
pyproject.toml is the standard configuration file. we're not interested in adding more config files
pipenv is recommended by pypa
it may not be standard but really all that has to be done is a check for the Pipfile in the same directory, and look for tool.black in the same way
Oh man, it's weird not seeing a cute cat where ever on the internet you're present Jelle.
I'm sure I'll get used to this one too, just needs time :)
other that pyproject.toml being the one file the most python projects will have, there's a cost to supporting formats especially with code complexity and maintenance
yes. we have to figure out what to do if both config files are present
and whatever we do will probably confuse someone
adding Pipfile support might not be that expensive from a maintenance perspective, but there's this good analogy Brett Cannon said: you're presenting us a kitten (it's low cost on its own) but when they grow up it's not so low maintenance / and arguably cute
and we have to draw the line somewhere and we prefer to draw the line defensively erring on the side of keeping maintenance sustainable
software almost always marches towards gaining limitless complexity from "just one more feature" and we'd like to slow that down at least :)
Since this hasn't been a common request and it would complicate our internals, I'm now inclined to reject this enhancement request. We can revisit that decision if we get more use cases.
If I understand you correctly, no since that only deals with configuration values, not the location
Describe the bug
Black raises INTERNAL ERROR when # fmt: skip has been added at the end of a def function statement
To Reproduce
For example, take this code:
def example(arg1: str, arg2: float): # fmt: skip
pass
And run it with these arguments:
$ black file.py
The resulting error is:
cannot format file.py: INTERNAL ERROR: Black produced different code on the second pass of the formatter
"""
--- source
+++ first pass
@@ -1,2 +1,...
at the time of that PR black even used Pipenv lol
Yeah, we've since stopped using it π
Oh, I didn't know it was a continuation of an ongoing discussion, my bad.
lot has changed since that PR
this is a duplicate issue, can't find the issue rn
will comment when i do
None of the labelled issues? There are some unstables, but no obvious duplicates, at least at a quick glance
i remember seeing an issue talking about fmt:off/skip on function definition lines
maybe wrong
would be good to find though!
ok nah can't find
atleast the labeled issues
ok found it
yeah it isn't labelled
oh, nice detective work
lol ty
oh how great
ig you missed this @bright glacier
And for adding isort to our dev dependencies, should I just rename test_requirements to dev_requirements or I have to add it somewhere else?
(or usort)
they are our dev requirements essentially
so renaming? why not, but anyways that's where I think they go
euh, I disagree with renaming it
We don't specify which mypy version we use other than in .pre-commit-config.yaml
i don't see any better place than π€·ββοΈ
same with flake8
hmmm
i willl just do that then
to be consistent with others
And if you could put your thoughts on usort/isort, so we can choose one
it could be worth it but I'd keep it in a separate file (maybe a larger dev-dependences.txt file) to avoid slowing down the test session setup
i never had the need of it, so its fine IMO
that could be nice, since the wider file can include from the test deps, so the dev setup wouldn't be any less convenient
@neon loom damn, we're really raising the standard of linter and autoformatter CI, even pytest has their own primer: https://github.com/PyCQA/pylint/issues/4413
Imitation is the best for of flattery
Is your feature request related to a problem? Please describe.
The except clause can accept a parenthesised tuple of exceptions. However, in the case of only a single exception the brackets should be removed.
Black currently leaves both of these examples unchanged:
a = 1
try:
a.something
except (AttributeError) as err:
raise err
and
a = 1
try:
a.something
except (AttributeError,) as err:
raise err
Describe the solution you'd like...
Hello Black community.
I write to you today to discuss the style outlined in the documentation for stub files (Python files meant for typing purposes with a .pyi extension). In the Black Code Style section of the documentation there is a section describing future style guidelines for the .pyi files: Typing Stub Files.
Description
The point I wish to argue against today is th...
Closes #2937. As described in the issue we want to remove redundant parentheses from except clauses.
Fixes #2938.
All of these suggested future changes are out of scope for an autoformatter and should be handled by a linter instead.
I see some false formatting changes here, https://github.com/psf/black/compare/main...Shivansh-007:experiment-isort?expand=1
not sure how i fix them, haven't messed up with isort yet
the config looks correct though
atleast if the docs aren't hiding anything
you should be using known_first_party not known_third_party for black and friends
third_party is for dependencies and first_party is for in tree code
oh shit yes, i didn't see that. ty π
also "adds an autoformatter to an autoformatter project" -> proceeds to use inconsistent formatting in the configuration π₯΄ lol
plz add spaces around the equal signs, kthxbye
lol will fix
Closes #2930
The formatting changes are part of commit 37356f6940773f0903486da9629b68bd78d47209 and edf37bf708006f12fc7d3cab43c21f19548b3035, the rest are config/chore changes.
no.
ok π
Isort: Fix typo third_part -> first_party
the typos are taking no prisoners
I'm surprised at the diff size
the only thing i am not 100% liking
i would have liked that to be broken down into 2-3 imports
also i still yet to try usort, it seems more promising
In general I prefer a single long from import over multiple imports but yeah it could be argued it's a bit much here
yeah even i do, but this a bit too big
i think there is a config option for that
will see
another one
It might be attaching semantic meaning to the comment
Isort has some interesting logic keeping sections relatively intact these days
yeah it does
i will give usort a try once
and then we could decide
but according to the features, i am more on usort
that pretty much sums it
Β΅sort operates on a strictly-parsed syntax tree of each file as a whole, rather than reading and parsing individual lines of text at a time. This guarantees that Β΅sort is modifying the actual Python syntax elements, along with any associated comments, and generating grammatically correct results after sorting.
one down side tho
Β΅sort uses case-insensitive, lexicographical sorting for both module names and imported items within each statement. This means uppercase or titlecase names are mixed with lowercase names, but this also provides a more consistent ordering of names, and ensures that frog, Frog, and FROG will always sort next to each other:
and there is no config oprtion for that
yeah I'd prefer constants in their own little group -> i.e. taking into account casing
yeah
couldn't see any issue re this in the current PR btw
Closes #2918. Ignores magic-trailing-comma for single tuple types in preview mode.
It might be better to separate the normal vs preview test data files instead of repurposing the stable ones as preview
yes, we haven't really thought about how testing works with stable vs. preview
Describe the style change
I think that redundant parentheses should be removed from generators or at least be allowed to stick to next/previous parenthesis. Consider the following source example:
any((
this_very_long_method_name(obj) or another_long_method_name(obj)
for obj in this_iterable
))
Examples in the current Black style
Now black (22.1.0) formats it to
any(
(
this_very_long_method_name(obj) or another_long_met...
Damn, this is some advanced sh*t.
Who is it?
I wonder for already a really long time
It even does not have a profile
Mysterious @github#0000
Oh, a webhook
Than i got it
This could be good PyCon sprint work for me maybe.
Any updates on psf/black#2863
My feeling is that that's intended behavior
workaround: black --config ../../pyproject.toml
flake8 stops at first flake8 found too ... I feel this determinism is something we want ... but I get the other side of there being no black config we could also keep going
This could be a breaking change to people who already exercise this behavior tho in practice
To Reproduce
file.py
with foo:
# yapf: disable
bar
baz
Run it with these arguments:
black file.py -t py39
The resulting error is:
INTERNAL ERROR: Black produced code that is not equivalent to the source.
Is black supposed to fail if it encounters stuff like
f"some text {'\n'.join((f' β’ {i}' for i in list_of_strings))}"
?
Does that work in Python 3.10? It fails on 3.9
With the same error that Black gives: "f-string expression part cannot include a backslash"
How do I see black errors in vscode?
At least the editor doesn't complain about anything
no, 3.8
yeah that's illegal syntax 
Yep, not a Black problem then I'm afraid
technically you could work around the issue by passing --fast but if the code isn't even valid Python, I don't see the point
Can't always trust editors :D
!e print(f"{'\n'.join([1, 2])}")
What specifically is the issue?
@bright glacier :x: Your eval job has completed with return code 1.
001 | File "<string>", line 1
002 | print(f"{'\n'.join([1, 2])}")
003 | ^
004 | SyntaxError: f-string expression part cannot include a backslash
The backslash
@shrewd zinc :white_check_mark: Your eval job has completed with return code 0.
1-2
None of the remaining guidelines sound AST-safe, but this is certainly better as is.
Thanks!
5379d4f stub style: remove some possible future changes... - JelleZijlstra
They're looking to fix this in 3.12
Integrating the f-string parsing with the peg parser makes it possible to parse it
peg parser?
Closes #2338. As described in the issue, we remove redundant parens from tuple unpacking in a for loop.
Black v22.1.0
The comment # IP6 address can look very different due to zero padding dissppears after black formatting.
Just pushed Rich 12.0.1 with a fix for piping on legacy Windows terminals. And some optimizations.
Describe the style change
I've just encountered an odd situation where black places a list index on a completely separately line.
Examples in the current Black style
Under default parameters, the following code snippet
def f(special_chars):
return (len([c for c in special_chars[1:] if c.isupper()]) > 0) and special_chars[0].islower()
is converted by black 22.1.0 to:
def f(special_chars):
return (len([c for c in special_chars[1:] if c...
Now reflects current state of the world.
Cool! Thanks for submitting a PR right away π Although there still is a warning about it being beta and possibly changing. So perhaps we should wait a bit? But I'm not totally opposed to changing it right away.
Most likely Prettier will complain about line lengths, but otherwise this looks good.
Thanks for the quick fix!
https://github.com/psf/black/pull/2948 ... uhhh where's the beta commit github?
Do I just manually merge the PR or something..?
at least GHA was a bit slow earlier
062b549 Github now supports .git-blame-ignore-revs (GH-... - ichard26
I'll just merge this one manually. Thanks for keeping the docs up to date! Congrats on your first PR to psf/black π
guess who forgot to change the commit author before committing this manually 
!remind 1M is the github .git-blame-ignore-rev blame support out of beta? don't forget to attribute https://github.com/henrikhorluck
Your reminder will arrive on <t:1648057593:F>!
!remind edit duration 4276 1m
That reminder has been edited successfully!
impressed you managed to edit the duration within the 1-minute window you had
I'm not that slow I swear π
gosh, why is this diff-shades integration so complex haha
anyway I think I should be able to update the PR in 30ish minutes assuming testing passes
What makes it so complex? Anything I could help on to try not make it so, sorry I've been at a distance with it all
The additional features we need π -- originally the integration would only show the impact of black using the projects' own configuration (or the defaults) but now we want to move away from that and instead force the preview / stable style
ahhh right
How you going to ensure preview does what it should? Just toggle if we expect changes or not?
had a real fun time trying to fix the latest bugbear error code too btw lol
B019, the diff-shades code is a bit hairy so I ended removing the caching altogether
I just released another one today with more fixes for some false positives on new checks
ambv talked me out of removing 3.6 support - Will do it when flake8 itself does it
Not sure what you mean, but now the integration has two jobs (well one more for run configuration, but we can ignore that) for PRs:
For pushes to main, only preview-changes runs.
Yup cool. Sounds great and answers what I was trying to ask.
The more I hack on this the more I think it'd make for a great blog post.. something something about real world testing with downstream :)
but I got other things to write about first (and other tasks to finish first before that)
https://github.com/ichard26/black/runs/5668459799?check_suite_focus=true it's always so satisfying to see this complex piece of CI work well π
hopefully it stays that way and doesn't fail in a way I don't expect
Cut issues for things / easy wishlist stuff you want and I'll come do some: https://github.com/ichard26/diff-shades/issues
So I can learn it
And @bright glacier - What power do you have now being on events team? Congrats
I was like, I like to party, I want a party hat
No more power actually, I just now get pings for all of the events python discord are planning and running 
I've been python discord staff for quite a while now
Run diff-shades compare --check assert-no-changes-main-450253afaf.json assert-no-changes-pr-15-8b2f244f34.json || echo "Please verify you didn't change the stable code style unintentionally!"
guess who messed up their bash conditional logic :p
I forgot to add the exit 1 at the end
bash is evil
I converted a script at work today to simple python cause I find it easy. from subprocess import run and have at it
it is configured but that bash command runs the second command if the former fails and I forgot that basically ignores the return code from GHA's perspective
.github/workflows/changelog.yml lines 18 to 21
run: |
grep -Pz "\((\n\s*)?#${{ github.event.pull_request.number }}(\n\s*)?\)" CHANGES.md || \
(echo "Please add '(#${{ github.event.pull_request.number }})' change line to CHANGES.md (or if appropriate, ask a maintainer to add the 'skip news' label)" && \
exit 1)```
see that && exit 1 ? that's what I need
Seems off topic for this channel, no? this is for the psf/black autoformatter project
oh, sorry I tought it was for open sorce projects, Im new here
this channel is indeed part of the open source project category but each channel is dedicated to a specific one python discord admins has vetted
ooh, I see, thanks man!
The Python Discord FAQ.
There's no channel for sharing your project, but the off topic channels usually work well enough assuming you'll doing it in good faith and are following the rest of the rules here.
!off-topic
Off-topic channels
There are three off-topic channels:
β’ #ot0-fear-of-python
β’ #ot1-this-regex-is-impossible
β’ #ot2-the-original-pubsta
The channel names change every night at midnight UTC and are often fun meta references to jokes or conversations that happened on the server.
See our off-topic etiquette page for more guidance on how the channels should be used.
thanks man!
haha, I'd be nervous having you look at the code given you're a professional dev and well ... I'm not one :p
I can do that though, I think I have a wishlist somewhere in notion π€
I'm a network engineer ...
Who likes to code. My code is horrible too.
Coding is fun, although I've been doing way more webdev than Python stuff lately
@bright glacier I'm submitting a talk to a conference in your poutine town