#black-formatter
flat krakenBOT
flat krakenBOT
silent knoll
#3 "allows including files from excluded directories" which seems like a good change to me
Also, it'd make sense to make that change in a major release
Btw, speaking of 26.1.0, I'm out of town this weekend but hoping to release it next week
mint barn
sup
dense jungle
#3 "allows including files from excluded directories" which seems like a good ch...
It probably makes sense but users who see that Black suddenly starts formatting a file we previously didn't format might get upset
True though that the 26.1.0 release is a good time to make that kind of change
But if we do something that changes behavior we should clearly call it out in release notes
flat krakenBOT
flat krakenBOT
silent knoll
bruh
silent knoll
fyi, ci is now failing due to the unexpected deprecation warnings
silent knoll
would appreciate a quick review from another maintainer, since this is a breaking change (and it's also blocking 26.1 due to the deprecation warnings causing ci to fail)
if anyone reading is on macos, i'd also appreciate someone testing https://github.com/psf/black/pull/4930
flat krakenBOT
flat krakenBOT
silent knoll
all 🟢 !
silent knoll
elder tusk
btw does anyone here have maintainer on pytokens? have two PRs open that will make Black much faster
silent knoll
@lavish scroll
lavish scroll
btw does anyone here have maintainer on pytokens? have two PRs open that will ma...
oh yes. i can test and release them
I'm also in SF this week! if you're around we can meet for coffee
elder tusk
yeah i could come into SF some day! also sorry we missed last time, i missed the linkedin email notif
what days/times/places work for you?
lavish scroll
what days/times/places work for you?
saturday 24th? Anywhere in SF is good. infact if you have any preferred cafes or such that'd be better as I'm so new to the US
tomorrow also works if you have a holiday
lavish scroll
@elder tusk another thing that's not documented but probably very useful: give pytokens a very large python project and it'll validate itself against python's builtin tokenize module
python -m pytokens --validate ../black
even better if the folder has a virtual environment full of third party modules, the more files the better
elder tusk
opened https://github.com/tusharsadhwani/pytokens/pull/15 with the ci build
elder tusk
saturday 24th? Anywhere in SF is good. infact if you have any preferred cafes or...
does lunch tomorrow work? maybe at spark social? i'd be taking the train in, so my main constraint is somewhere walkable from caltrain
lavish scroll
does lunch tomorrow work? maybe at spark social? i'd be taking the train in, so ...
i don't have confirmation on if people will be working from office tomorrow or not 🫣
if saturday works that'd be great
lavish scroll
opened https://github.com/tusharsadhwani/pytokens/pull/15 with the ci build
Getting
Couldn't find 'uv' in PATH
errors on main
all the linux ones are solid
elder tusk
ah i made the uv change after verifying the build on all platforms. let me just remove it
elder tusk
the install script is different on windows, i think not worth it
lavish scroll
cool
I'll release a 0.4.0 tonight
We should add a >=0.4.0,<0.5 in the black pyproject, right now it just picks the latest
unless python understands 0ver and doesn't upgrade minor versions for 0.x
silent knoll
python tooling doesnt follow semver at all from what i can tell which is a major flaw imo coming from a node background
elder tusk
sg! although in this particular case it's actually quite nice that most black users will pick up the perf fix 🙂
silent knoll
pathspec was at >=0.something and pip was installing v1 once it got released
lavish scroll
wow
lavish scroll
sg! although in this particular case it's actually quite nice that most black us...
true!
but going forward we can adopt best practice 😂
pytokens is a big enough part of black that we should update it lockstep with black versions imo
pytokens patches being upstreamed as black patch updates etc
silent knoll
python tooling doesnt follow semver at all from what i can tell which is a major...
if we change >=s to ~s it'll only auto-bump up teo the last number written (so if you only include two numbers it'll bump the second and third ones, whereas if you include three numbers it'll only bump the last one), which is similar to npm's ^ syntax
I'm not certain how python dependencies get installed though
To my understanding if a user tries to install package==1.1.0 as well as black, but if black uses package~=1.0.0 i think that causes problems
So we should to avoid narrowing dependency versions when possible
We should definitely move dev-only dependencies to that though, especially now that most things are properly updated with Dependabot
Some deps don't even define a version and just install latest
lavish scroll
I'll release a 0.4.0 tonight
it's out
silent knoll
https://github.com/PyCQA/isort/issues/2452
don't think there's anything we can do at this point since it's been released
silent knoll
we could theoretically remove the normalization all together in a patch release, then change it to normalize to two lines next year
but that's the same noise two years in a row for everyone who already changed
i don't think we ever had a discussion on 1 vs 2 lines after imports but from the points made in the issue i think 2 lines is better (1 line is used between import groups already so 2 lines would be better to break imports up from the rest of the file; if the first thing after the imports is a function/class there's going to be 2 blank lines anyway so it should be 2 lines all the time)
azure plank
Trying to set up the project for dev again and doing my normal thing (clone, uv venv, uv pip install the things) I get this, was sphinx recently updated?
PS ~\Documents\python_projects\black>uv run .\src\black\__init__.py "C:\Users\GiGaGon\Downloads\pygettext.py"
× No solution found when resolving dependencies for split (markers: python_full_version == '3.10.*' and sys_platform
│ == 'win32'):
╰─▶ Because the requested Python version (>=3.10) does not satisfy Python>=3.11 and sphinx==8.2.3 depends on
Python>=3.11, we can conclude that sphinx==8.2.3 cannot be used.
And because black:docs depends on sphinx==8.2.3 and your project requires black:docs, we can conclude that your
project's requirements are unsatisfiable.
hint: The `requires-python` value (>=3.10) includes Python versions that are not supported by your dependencies
(e.g., sphinx==8.2.3 only supports >=3.11). Consider using a more restrictive `requires-python` value (like
>=3.11).
hint: While the active Python version is 3.14, the resolution failed for other Python versions supported by your
project. Consider limiting your project's supported Python versions using `requires-python`.
I'm looking in to this and so far my conclusion is I don't think this file is actually encoded using iso-8859-1, but I'm not sure what
azure plank
That's also what I'm trying to look at, I think I'm seeing the same thing? J\xfcrgen
No wait that is correct
>>> "Jürgen".encode("iso-8859-1")
b'J\xfcrgen'
>>> "Jürgen".encode("utf-8")
b'J\xc3\xbcrgen'
Sphinx wasn't bumped, but it was previously defined in docs/requirements.txt while now it's a dependency group in pyproject.toml
azure plank
Hm, so I guess that makes uv now see it and recognize a potential conflict
I wonder if I'm just using uv wrong
silent knoll
I've been using venv without an issue
azure plank
hm
Adding a print it looks like we should recognize the encoding correctly as iso-8859-1
It looks like the cause is from passing the normalized contents into lib2to3_parse instead of the src_contents
# 2002-11-22 JÃÂürgen Hermann <jh@web.de>
silent knoll
i think i found it
we call decode_bytes twice
once in format_file_in_place/format_stdin_to_stdout and again in _format_str_once
azure plank
Ah, so we're double-decoding it
I think we already did that in the past? But the newline handling worked fine, the issue now is that I passed that double normalized contents into lib2to3_parse when we normally only used it for newline detection in _format_str_once
silent knoll
we did not previously call decode_bytes in _fmt_str_once
src_contents here is already decoded, so we can ignore normalized_contents here entirely
silent knoll
oh i see
yeah, the double-decoded source was originally only used for this check, so we should still use src_contents in lib2to3_parse
i'm not sure what that check is doing, should we be double-decoding there?
apparently it's checking if the file is whitespace-only but i'm not sure how that works
azure plank
I think that check is for if a file put into black was nothing but newlines, since in that case the formatting process removes them all, so we return a single newline
silent knoll
ah i see now
what if we just
i believe the change there is it would format fully-empty files as one blank line instead of keeping them fully empty
azure plank
I think that's what it's trying to avoid
silent knoll
wait yeah'
because then it'd be two blank lines in the file, right
but yeah we could use the single-decoded version there just fine
yeah, src_contents isn't changed since it's decoded
azure plank
So the fix should be pretty simple, the question is what should we do on the releases side?
silent knoll
i mean this feels pretty small to warrant a patch, but then again, it's corrupting comments
possibly could corrupt more too
but it is very much an edge case
we should probably see if anything else pops up this week at least
silent knoll
more pushback https://github.com/psf/black/pull/4489#issuecomment-3767404526
and try to decide something about this
azure plank
I think this would only affect non-utf-8 files?
silent knoll
yeah
silent knoll
oh i've almost got one up already
azure plank
Then feel free
silent knoll
hm tests are failing
azure plank
It looks like it's not that PR? Since just running black on it's own fails too ```
PS ~\Documents\python_projects>uvx black -c "try:\\r# type: ignore\n pass\nfinally:\n pass\n"
try:\\r# type: ignore\n pass\nfinally:\n pass\n
error: cannot format <string>: Cannot parse: 1:3: Failed to parse: UnexpectedCharacterAfterBackslash
Oh wait I stupid
Ok it does work normally, I just forgot powershell is funny
azure plank
hm tests are failing
Oh wait that does make sense, the reason I used the normalized version in the first place is so that all the newlines would be \n and we didn't have to worry about \r breaking the parser
The actual fix would be passing in the encoding and using it instead of always defaulting to utf-8 in src_contents.encode("utf-8")
silent knoll
Oh wait that does make sense, the reason I used the normalized version in the fi...
does TextIOWrapper do that? there's nowhere in decode_bytes where we manually change line endings
azure plank
It's the read call, reads in python by default make all newlines into \ns
silent knoll
interesting
azure plank
return tiow.read(), encoding, newline
silent knoll
why isn't that done the first time it's called then
azure plank
hm, it should be? src_contents, encoding, newline = decode_bytes(buf.read(), mode)
silent knoll
odd
azure plank
It might be because some calling paths don't go through that first decode_bytes call and skip straight to _format_str_once
azure plank
So I think we should add an encoding: str = "utf-8" to _format_str_once and thread that through format_file_contents from those two other places that use decode_bytes (with the default argument since otherwise someone/our code will complain about the new arg)
silent knoll
maybe we could change format_file_in_place to just get the encoding and newlines, and pass the undecoded version to format_str, and decode in _format_str_once again
i have to go but will look at this more this evening, or you can feel free to push to my pr if you want
azure plank
Sounds good
azure plank
Thinking about it more I've found a better solution: The reason everything is going wrong is because while _format_str_once encoded the str as utf-8, tokenize.detect_encoding still sees the magic iso-8859-1 encoding sequence, so we decode the utf-8 with iso-8859-1, causing the whole mess. So the solution that prevents a bunch of non-local changes is to instead add an encoding_override parameter to decode_bytes that skips tokenize.detect_encoding if present to prevent the magic encoding sequence from messing it up
Though there is I guess a possible edge case? If tokenize.detect_encoding eats the first couple lines then the newline detection in decode_bytes actually is using not the first newline. Oh well I guess.
I also wonder if there are any encoding schemes that use newlines that aren't the standard bytes, which would make our newlines tests always give \n
runic monolith
@azure plank hello sir
azure plank
o/
azure plank
!rule 6 9
late dewBOT
azure plank
I pushed the updated fix, but CI is still unhappy with the file :(
I guess I'll have tofigure out how to actually make it a test_black test
silent knoll
I actually already did that but hadn't pushed because it wasn't working yet
azure plank
Hopefully it will with our powers combined?
silent knoll
I'm realizing I might need to construct a buffer and convert it to a string
For now I edited it using a hex editor, let's see if that works
yeahh
azure plank
Hm, it should already be right, since I used .write with a file opened in wb mode
silent knoll
tests/test_black.py needs to be readable as a utf8 file
azure plank
Oh if you're doing it in test black just use a b string
I was talking about in cases
silent knoll
ah
azure plank
That's what I was struggling on, we can't really use any of the existing things since they take strings and we want to test the double encoding, so it has to be a tempfle
Which are confusing ;-;
Unless you found some way around that
silent knoll
Lemme try running it with format_file_in_place instead
looks like it's working now
just forgot to format self
gtg
azure plank
gaming
I wonder if now that it's working in the data dir if it would be worth moving to a temp file so the binary data is more clearly exposed/editable, or if we should just accept that it works in the data dir and move on
silent knoll
i mean, i thought it was easy enough to use a hex editor, but either way if you can figure it out
also, I'm not sure why github isn't properly rendering it in first_line.py, it has the same hex data
azure plank
That's my main point of concern, the fact that some editors just perish
So if in the future we ever need to update these tests for whatever reason that persons editor may decide to be stupid and re-encode it as utf-8
silent knoll
we could add an assertion that the files have non-utf8 data
azure plank
Let me see if I can make it work with tempfile + the ff, and if not lets go with that
Got it working :)
This works, but the error you get when it fails kinda sucks thanks to the assertFalse just being "true is not false"
with NamedTemporaryFile(delete_on_close=False) as first_line:
first_line.write(
b"# -*- coding: iso-8859-1 -*-\n# 2002-11-22 J\xfcrgen Hermann"
b" <jh@web.de>\n"
)
first_line.close()
self.assertFalse(ff(Path(first_line.name)))
with NamedTemporaryFile(delete_on_close=False) as second_line:
second_line.write(
b"#! /usr/bin/env python3\n# -*- coding: iso-8859-1 -*-\n# 2002-11-22"
b" J\xfcrgen Hermann <jh@web.de>\n"
)
second_line.close()
self.assertFalse(ff(Path(second_line.name)))
though that also applies to the existing apporach, I wonder if there's a way to fix it
silent knoll
though that also applies to the existing apporach, I wonder if there's a way to ...
assertFalse takes a second msg argument
flat krakenBOT
silent knoll
https://github.com/psf/black/pull/4489#issuecomment-3767404526 @dense jungle Could you take a look at the discussion here when you have a chance?
dense jungle
https://github.com/psf/black/pull/4489#issuecomment-3767404526 <@783088578363523...
I don't have much to add there. The nature of style decisions like this is that some people will be unhappy, I bet we'd also have gotten some people up in arms if we'd chosen 2 newlines. I don't think this is bad enough that we need to be concerned.
azure plank
I agree on thinking about it some more. A couple comments is all things considered fairly minor. If we were seeing a constant influx of new duplicate issues about it that would be cause for more concern, but it seems most people's CI should have run by now and they don't care.
My main concern right now (besides figuring out where the cases test infra is for the double encoding bug) is actually figuring out what to do about the playground, since it's very :/ that we still haven't been able to get that updated
flat krakenBOT
silent knoll
This works, but the error you get when it fails kinda sucks thanks to the assert...
Are you able to push this to the PR?
We haven't gotten any other issues, so I think it's good to move on and not plan on releasing a patch
If we feel it's urgent we can release a 26.2.0 in not too long
silent knoll
Also, PRs that are ready but need discussion/maintainer opinion/testing:
https://github.com/psf/black/pull/4916
https://github.com/psf/black/pull/4925
https://github.com/psf/black/pull/4930
winged mulch
Also, PRs that are ready but need discussion/maintainer opinion/testing:
<https:...
Hey, what channel would i go to for like general code help?
silent knoll
Probably #1035199133436354600
winged mulch
oke
silent knoll
fuzz...
silent knoll
MRE for fuzz error:
if True:
if True\
:
pass
Doesn't matter where in the line the backslash is or what kind of block it is, the bug is triggered whenever the line after the backslash is indented less than the line the backslash is on
(so something like this is fine:
if True\
:
pass
``` because the : is on the same level as the if)
there was also a mix of `\r` and `\n` in the generated code but it doesn't make a difference herei think it's something that needs to be fixed in pytokens
lavish scroll
i think it's something that needs to be fixed in pytokens
👀
if you were able to get an MRE with pytokens that'd be great
if pytokens output is different from builtin tokenize output on python 3.14, then we should fix it in pytokens. else, fix in black
silent knoll
MRE for fuzz error:
```py
if True:
if True\
:
pass
```
Doesn't matte...
I confirmed that pytokens fails with --validate and this mre
lavish scroll
great. I'll take that up
silent knoll
I feel like we should stop running Fuzz on PRs, it tends to just start failing unpredictability and usually unrelated to the PR
I wonder if it would be difficult to have the action open an issue instead of crash
barren flint
Hello, everyone, how i will get open issues so that i can contribute.
it seems every issue is solved or closed
young sand
I wonder if it would be difficult to have the action open an issue instead of cr...
We have that kind of workflow over at ruff here, it's not too complex: https://github.com/astral-sh/ruff/blob/main/.github/workflows/daily_fuzz.yaml
Not exactly the same workflow but a very similar one, if you want to see what the issues look like when the daily test fails: https://github.com/astral-sh/ty/issues/2341
These workflows run on a nightly cron job rather than on PRs, though
lavish scroll
@silent knoll I'm making a primer-like for pytokens, will be great to have that up to test your patch
silent knoll
good to know
right now i'm running --validate against black
https://github.com/tusharsadhwani/pytokens/pull/19 @lavish scroll
silent knoll
https://github.com/psf/black/pull/4968 I'm starting to think that these accounts are purely run by ai and not even just a human passing everything to chatgpt
dense jungle
what did they think was going to happen
elder tusk
probably that black would add the whitespace
radiant linden
hola
agile vale
Hi! I've opened PR #4971 which consolidates Jupyter Notebook documentation into a single comprehensive page. It's a documentation-only change (no code changes). The changelog CI check is failing because I didn't add a CHANGES.md entry - I assumed docs-only changes don't need one. Could a maintainer add the 'skip news' label to the PR, or should I add a changelog entry instead? Thanks!
carmine coyote
Hello there! I have an
$ uv run black f.py -vvv
Identified `p` as project root containing a .git directory.
Using configuration from project root.
line_length: 100
target_version: ['py312', 'py313', 'py314']
Found input source: "f.py"
Traceback (most recent call last):
File "src/black/__init__.py", line 909, in reformat_one
File "src/black/__init__.py", line 952, in format_file_in_place
File "src/black/__init__.py", line 1078, in format_file_contents
File "src/black/__init__.py", line 1214, in format_str
File "src/black/__init__.py", line 1225, in _format_str_once
File "src/black/parsing.py", line 98, in lib2to3_parse
black.parsing.InvalidInput: Cannot parse for target version Python 3.14: 25:12: <!DOCTYPE html>
error: cannot format f.py: Cannot parse for target version Python 3.14: 25:12: <!DOCTYPE html>
Oh no! :boom: :broken_heart: :boom:
1 file failed to reformat.
issue - but https://black.vercel.app/?version=main works as expected 😕
... but it is outdated (Stable: 25.1.0 | Main: @314f8c, https://github.com/psf/black/commit/314f8c is from May 2025)
I am guessing that I have the correct executable - and not some "messed up" one
{ url = "https://files.pythonhosted.org/packages/e4/3d/51bdb3ecbfadfaf825ec0c75e1de6077422b4afa2091c6c9ba34fbfc0c2d/black-26.1.0-py3-none-any.whl", hash = "sha256:1054e8e47ebd686e078c0bb0eaf31e6ce69c966058d122f2c0c950311f9f3ede", ...
Idk - should I open an issue to discuss? or talk here?
dense jungle
Hello there! I have an
```
$ uv run black f.py -vvv
Identified `p` as project r...
Yeah the playground is outdated, we don't control it. I'd ignore it.
Can you share (a minimized version of) your code? From what you showed it seems Black is in the right to think there's a syntax error, but maybe there's something odd going on.
carmine coyote
In that case, would you consider removing it from your instructions? 🙏
dense jungle
Yeah we probably should
carmine coyote
Basically it seems that black doesn't like
with open(d / "DO_NOT_EDIT", "w") as f:
f.write(
textwrap.dedent(
"""\
# Do Not Edit
"""
)
)
and prefers
with open(d / "DO_NOT_EDIT", "w") as f:
f.write(
textwrap.dedent("""\
# Do Not Edit
""")
)
instead (which I don't like, but I get it, black is opinionated)
So I am trying to "outsmart" it by
with open(d / "DO_NOT_EDIT", "w") as f:
f.write(
textwrap.dedent( # fmt: skip
"""\
# Do Not Edit
"""
)
)
in the original case my string literal included <!DOCTYPE html>; in this case, I get
$ uv run black f.py -vvv
Identified `p` as project root containing a .git directory.
Using configuration from project root.
line_length: 100
target_version: ['py312', 'py313', 'py314']
Found input source: "f.py"
Traceback (most recent call last):
File "src/black/__init__.py", line 909, in reformat_one
File "src/black/__init__.py", line 952, in format_file_in_place
File "src/black/__init__.py", line 1078, in format_file_contents
File "src/black/__init__.py", line 1214, in format_str
File "src/black/__init__.py", line 1225, in _format_str_once
File "src/black/parsing.py", line 98, in lib2to3_parse
black.parsing.InvalidInput: Cannot parse for target version Python 3.14: 22:0: Unexpected EOF in multi-line statement
error: cannot format f.py: Cannot parse for target version Python 3.14: 22:0: Unexpected EOF in multi-line statement
Oh no! 💥 💔 💥
1 file failed to reformat.
(Actually it seems that this snippet can also be replicated in https://black.vercel.app/ aka 25.1.0)
flat krakenBOT
silent knoll
We should add a >=0.4.0,<0.5 in the black pyproject, right now it just picks the...
or not
i may still be misunderstanding how python dependency resolution works
lavish scroll
i may still be misunderstanding how python dependency resolution works
maybe me too lol
but we should be using 0.4.1 right now afaik
silent knoll
but we should be using 0.4.1 right now afaik
we are, but it sounds like we shouldn't add upper bounds on anything
pytokens might be an exception though since it's so fundamental to black and it's unlikely to be used by anything else. not sure. again i need to do more research on dep resolution
dense jungle
yeah pytokens is one where it might make sense since the projects are closely tied
but if we add a bound now resolvers might in the future give people old black + new pytokens
which is probably the worst combination
little parrot
<@&831776746206265384> ^
civic bane
!compban 1146373822493241375
late dewBOT
:incoming_envelope: :ok_hand: applied ban to @upper raft until <t:1770337338:f> (4 days).
dense jungle
wouldn't that be a possibility anyway?
Not if we depend on pytokens without an upper bound
silent knoll
i believe it could happen if someone were to pin black to an old version, which obviously isn't supported but it's probably relatively common if people don't like a chance black made one version
if we added an upper bond it'd still be old but at least it should be old versions of both
lavish scroll
but if we add a bound now resolvers might in the future give people old black + ...
if i bump pytokens to 1.x will that prevent old blacks from using it?
dense jungle
no
carmine coyote
Hello there! I have an
```
$ uv run black f.py -vvv
Identified `p` as project r...
Anyone would like to finish the discussion about a parsing error above? 😕
silent knoll
Probably should release a 26.2.0 at some point then
silent knoll
https://github.com/mozilla-releng/balrog/pull/3617 a third known affected project
glad pilot
@silent knoll Can you clarify what it is that you're advocating for on this python3.12 -m black -t py314 issue? Am I correct in understanding that you're suggesting that Black should emit a warning saying that it may fail due to the use of -t with --safe, but then keep running and go on to fail with the same INTERNAL ERROR that it fails with today?
glad pilot
(I figure it's easier to have a conversation here that might involve some back and forth than on the issue 🙂)
elder tusk
printing a warning with version mismatch instead of doing the safety check seems like a good idea to me (esp since black really is fairly safe these days)
mypy will be shifting to some new parsing tech soon and maybe we could reuse that instead of stdlib, would maybe be faster too (tho iirc we exclude a few things from ast safety and would need to figure out the equivalent)
glad pilot
Some whitespace changes to docstrings are definitely excluded from the AST safety check
flat krakenBOT
hollow temple
https://www.githubstatus.com
it back to work perfectly !
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
peak ridge
Hello how to learn python
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
silent knoll
Trying to set up the project for dev again and doing my normal thing (clone, uv ...
The cibuildwheel we currently use is also 3.11+, and the next version of Sphinx is 3.12+
I think it makes sense to encourage developing on 3.11+ (which again, we already implicitly do, but the only thing that explicitly says another version is release.py being documented as 3.12+), maybe even 3.12, but there's no PEP735 way to declare requires-python for specific dependency groups
I use venv and pip as recommended in the docs without an issue, even though there's "conflciting" versions, since i'm using 3.12 pip doesn't care
But some tools (uv) might yell at you
And we also don't get Dependabot PRs for 3.11+-only deps (see: the cibuildwheel pr was supposed to bump in pyproject.toml too, but didn't because it's 3.11+ and we "support" 3.10+)
silent knoll
uv does support it but it's not standardized for other tools
The main solution I can think of would be to set requires-python dynamically so we can use whatever deps in [dependency-groups] with dependabot supporting them and without uv or other tools getting mad, and people installing the built project still get the correct constraints
silent knoll
https://github.com/pypa/hatch/issues/2110 Doesn't look like Hatch has done anything about the bug yet
delicate sparrow
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
jade thicket
💯
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
lyric rune
wow
flat krakenBOT
flat krakenBOT
flat krakenBOT
silent knoll
stop
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
silent knoll
oop didnt realize it had already been closed :p
dense jungle
oop didnt realize it had already been closed :p
I was also writing something just as Shantanu closed it 😄
silent knoll
oh, it's not even stable until october
didnt realize
only one more release until beta & no more new features though
dense jungle
yes, though it's likely we'll get a flurry of new features right before the beta
there's potentially a few that will affect Black, like the ones for d-strings and for mixing sync/async context managers
so probably best to wait for beta 1
silent knoll
it looks like libcst (needed for fuzz) doesn't yet support 3.15
eh it's still a while off
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
silent knoll
good idea, but would require larger changes to the release workflow
currently we upload assets in an action triggered on release, but you can't add new assets to an immutable release
the action would have to publish the release itself and upload the assets at publish-time
unique swallow
drowsy jolt
one approach is upload assets into a draft release, then publish the release when ready
young sand
I think that's what we do for Python-build-standalone, IIRC
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
drowsy jolt
Now Python 3.15 beta is out, would be nice to have a new Black release at some point to support lazy and unpacking in comprehensions. I think it's already supported in main?
quartz acorn
Hey I’m white can I talk here anyway?
flat krakenBOT
dense jungle
Now Python 3.15 beta is out, would be nice to have a new Black release at some p...
just sent a PR adding CI coverage. I think mypyc doesn't support 3.15 yet so we'd have to have a pure Python release only for now?
dense jungle
we do already support PEPs 798 and 810
drowsy jolt
No mypy wheels until RC: https://github.com/python/mypy/issues/21229#issuecomment-4292022910
A pure Python release of Black would still be useful
elder tusk
fwiw i think mypyc should work on 3.15, it is just not itself compiled (but we shouldn't be uploading wheels prior to rc either)
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
jade hollow
Hey I’m white can I talk here anyway?
Um im purple can i talk here?
silent knoll
yes, though it's likely we'll get a flurry of new features right before the beta
Doesn't look like there was anything else? Are we good to release 26.5 now then?
Also unrelated, but would there be any objection if I went through and closed all the multi-year stale PRs?
dense jungle
agree on both!
flat krakenBOT
azure plank
Cleanup :)
silent knoll
hmmm...still failing on windows
silent knoll
okay, they all got uploaded now
young sand
it looks like the pre-commit-mirror repo is not going to update automatically FYI: the scheduled GitHub Action has been disabled by GitHub due to "lack of activity" in that repo: https://github.com/psf/black-pre-commit-mirror/actions/workflows/mirror.yml
(I looked because I wanted to update typeshed's black pin, and typeshed runs black via pre-commit 😄)
drowsy jolt
Forget security (don't tell Seth...), this is actually the biggest benefit of having a monthly Dependabot/Renovate update the actions! Hash pin them too, again not for security, but to more likely guarantee a monthly PR 🙃
dense jungle
I pushed some buttons and now it should run
drowsy jolt
The actions have not been updated for 3 years, and have a deprecation warning, so do need a bump
dense jungle
I don't think I can do that while listening to Pablo talk
drowsy jolt
Is he faster in English or Spanish?
silent knoll
Anyone familiar with Vim here able to review https://github.com/psf/black/pull/5124 ?
bright glacier
Anyone familiar with Vim here able to review https://github.com/psf/black/pull/5...
done ✅
flat krakenBOT
silent knoll
CI failures casued by Click update - pallets/click#2805
toxic stormBOT
flat krakenBOT
silent knoll
I don't know how to fix this
I had to rerun the actions on main with the fixed workflow, but it uses the tagged commit for the version, and main wasn't tagged once I fixed the workflow
dense jungle
I don't know how to fix this
probably need a new release
flat krakenBOT
dense jungle
^ that one looks pretty good, maybe let's land it and make a new clean release? @silent knoll
silent knoll
sure, sounds good
5124 and 5130 also seem ready to merge, if we want to include them
dense jungle
5124 and 5130 also seem ready to merge, if we want to include them
agree, merged one and approved the other, it can land when CI passes
silent knoll
👍 shades was passing with no changes before, fwiw, i just merged main to fix the test failures caused by the click update
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
flat krakenBOT
austere lava
o/
prime gull
Welcome, people of the black formatter!
marble citrus
hey
onyx furnace
Hello
subtle mica
👋
hazy spire
whats black-formatter
desert remnant
👋
solid condor
💙
marble citrus
i dont even know python why am i here
night hollow
Hello World!
prime gull
whats black-formatter
marble citrus
got pinged
woeful orbit
Hi
silent apex
I use pyproject.toml
Same
neon loom
Howdy all
silent apex
I find it easiest to keep everything in one place
solid condor
https://github.com/psf/black
might be worth pinning
plain atlas
late dewBOT
pyproject.toml lines 55 to 58
[tool.black]
line-length = 99
target-version = ['py38']
include = '\.pyi?$'```It's in the channel description
mint barn
ih
onyx furnace
Will it be available as a vsc extension in the future?
solid condor
the website and github issues are and some people will check pins first
mortal igloo
o/
bright glacier
Hi, it's @bright glacier 👋
prime gull
the website and github issues are and some people will check pins first
tbh, the people who would actually check pins are the ones who would look at the channel topic anyway
mortal igloo
True
solid condor
yeah 😛
ripe jackal
Welcome! c:
idle grail
🖤
bright glacier
tbh, the people who would actually check pins are the ones who would look at the...
As a maintainer, it's frustrating at how many people miss the pinned issues lol
It is what it is tho
rocky wharf
Hi :D
vivid pasture
o/
mellow grail
black is so good
jagged pivot
Black developers and users are invited to use this channel
very open to misinterpretation
bright glacier
yep, typically why I use "maintainers of black" as example
jagged pivot
yeah, perhaps "Users and developers of black are invited to use this channel..."
mellow grail
O.o
bright glacier
Will it be available as a vsc extension in the future?
Well, there's built-in support for black in vscode, no?
halcyon latch
_>
<_<
wdym it's always said that suggestion....
plain atlas
>\_>
<\_<
wdym it's always said that suggestion....
it originally always suggests autopep8
plain atlas
and right now vsc is causing me some issues so im not gonna talk about it atm.…
halcyon latch
it originally always suggests autopep8
Whoops, quick message. That was meant as a response to the channel description
bright glacier
We gave up on using IRC as our platform, it was just me and cooper on there most of the time anyway
halcyon latch
I miss the IRC days, but ngl, I love the emojis of discord 
plain atlas
lol i know a still active irc
jagged pivot
heavy summit
👋
split merlin
Love black, been using it for ages for my personal projects. And help snippet for here.
rapid yoke
Hi, what is this?
heavy summit
Hi, what is this?
see channel description 🙂
rapid yoke
Thanks
bright glacier
This is a project specific channel, RIP IRC
rapid yoke
Seems odd to have a project specific channel
bright glacier
Whelp, we managed to convince Python Discord to start this so yeah
heavy summit
We might consider other partnerships in the future if this works out
tribal thistle
Glad to have y’all here
neon juniper
We might consider other partnerships in the future if this works out
yeah that'd be good :)
rapid yoke
Glad to be here
neon loom
Seems odd to have a project specific channel
We want to have our development chat in a more open place
So others can join in and offer opinions and even help 😄
But I don't want to take over more generic channels on a busy day
rapid yoke
What, you input a code file and it outputs it in pep8 or something? I should really read the docs hang on
bright glacier
gasp
rapid yoke
Nice
neon juniper
I guess this isn't the place to be discussing tabs vs spaces haha
rapid yoke
4 spaces
silent apex
An editor that turns a tab into four spaces
heavy summit
Maybe we could add a black command that would format the code? Like
!black
def foo () -> tuple [ int
, str ] :
return ( ( bar ) )
def foo() -> tuple[int, str]:
return bar
haha
rapid yoke
Wait did u echo that?
delicate marsh
hahaha that's a fun idea
bright glacier
I guess this isn't the place to be discussing tabs vs spaces haha
Yeah no.
short forge
Eval args mayhap?
rapid yoke
Maybe we could add a `black` command that would format the code? Like
!black
```...
That code is a monstrosity
neon loom
@solid adder has done most. But the leading 4-5 contributors are here
neon loom
I guess this isn't the place to be discussing tabs vs spaces haha
What are tabs?
rapid yoke
Lol
bright glacier
<@!688057416062861319> has done most. But the leading 4-5 contributors are here
Me, @neon loom , @dense jungle , @solid adder , and @austere lava to be specific
delicate marsh
Eval args mayhap?
yeah, with the new eval stuff we can very much install black into https://git.pydis.com/snekbox and then use eval args to run black on input
rapid yoke
I might work on the thing that fix error suggested
austere lava
I've been outed
heavy summit
That code is a monstrosity
You haven't seen this, have you https://paste.pythondiscord.com/orinimetep.py
neon juniper
oh no
bright glacier
why does that even exist
rapid yoke
🤮
heavy summit
there's also a way to move the % and == to the right, but I'm lazy
rapid yoke
That’s actually pretty cool, not as actual code but still
bright glacier
I mean, you would've been uncovered eventually zsol 😉
plain atlas
yeah, with the new eval stuff we can very much install black into <https://git.p...
also could create a format command with blackd
and run a blackd server
split merlin
Mostly recognise you from helping ichard
bright glacier
also could create a format command with blackd
Would be faster, although honestly I don't know if blackd has been well maintained lol
I have not looked at it in quite a while
plain atlas
yay finally someone gave you your roles
wooden socket
is there some problem with type annotations?
I'm getting a "Cannot parse" error on this line:
def write_event(session: str, type: str, xcoord: int, ycoord: int, direction: int, timestamp=None: str) -> None:```are you ok? you're all purple
halcyon latch
so much purple in this channel, I love it 
bright glacier
are you ok? you're all purple
no, I need to find a can of black paint ASAP
heavy summit
is there some problem with type annotations?
I'm getting a "Cannot parse" error ...
timestampe: str = None
the annotation goes first
tribal thistle
First legitimate help question. That was quick.
austere lava
is there some problem with type annotations?
I'm getting a "Cannot parse" error ...
it should read timestamp:str = None
plain atlas
can the black partner role be colored black
exotic swift
Hello
wooden socket
`timestampe: str = None`
the annotation goes first
ah got it, thanks 🙂
rapid yoke
@bright glacier what black magic is going on with your colours?
bright glacier
hmm, looks like a glitch lol
rapid yoke
Yeah it seems to have fixed itself when I reloaded discord, sorry for the ping lol
bright glacier
Ah, don't worry, it's not like I'm drowning in notifications already (email walking behind about to jump me)
rapid yoke
Lmao
bright glacier
See topic
spring egret
what is black formatter
bright glacier
Oh ok, so we wanted a more open and transparent area for our communication, we used to use a mix of private chats and IRC but they weren't great for reasons I don't want to get into right now
spring egret
Ooo
neon juniper
this is what you get https://paste.pythondiscord.com/roxaxinaxa.php
spring egret
Okay thank you
neon juniper
which is pretty in its own way...
halcyon latch
@little folioAre you familiar with PEP8, Python's style guide? This is a fantastic tool that will help your code stay within those guidelines making it more readable for everyone.
late dewBOT
neon juniper
yeah that seems fair haha
silent apex
That's better than what is was before
echo eagle
Maybe we could add a `black` command that would format the code? Like
!black
```...
That’s actually a pretty fun idea
bright glacier
<@!535866091688165411>Are you familiar with PEP8, Python's style guide? This is ...
cough cough it's a tool / an application, not a library, we don't have an official Python API (although we may have one in the future)
prime gull
That's better than what is was before
i can somewhat follow the logic unlike before 
halcyon latch
*cough* *cough* it's a tool / an application, not a library, we don't have an of...
... you saw nothing
silent apex
i can somewhat follow the logic unlike before <:kek:585617800257863727>
Same
neon juniper
*cough* *cough* it's a tool / an application, not a library, we don't have an of...
an API for black would be neat! I'd love to help out with that
rapid yoke
Hi sebastiaan 👋
ionic nymph
black's amazing. I was a bit hesitant at first, because I was used to slightly different stylistic choices, but it just takes away having to discuss style.
bright glacier
an API for black would be neat! I'd love to help out with that
dense jungle
I'd be happy to 🙂
austere lava
Funny how that issue references the first stable release in april