#black-formatter

1 messages Β· Page 17 of 1

bright glacier
#

We also never really discussed python 2 formatting support

#

and we were forced to a bit when making changes that depends on python 2

#

not enough clearly

drowsy sonnet
#

(nvm, I'm gonna go respond there so that you can point fingers at me and randos can argue with me there)

bright glacier
#

fun

dense jungle
#

I imagine you're going to say "drop Python 2 yesterday"? πŸ™‚

bright glacier
#

it's part of the maintainer experience πŸ™‚

errant barn
#

Got to say. Once again, I'm quite excited about the fuss here!

red sedge
#

I no longer use python 2, and so am unbiased.

#

Literally merged my pyupgrade PR yesterday

bright glacier
#

I feel like by the end of this year would be reasonable (or on stable release or the next one after that)

#

It's been ~two years since 2020

red sedge
#

It's still march 2020 where I am

bright glacier
red sedge
#

It's got some handy features like bytes in csv

bright glacier
#

Sounds great!

#

I guess Black is going through the late-stage growing pains process that like any major projects goes through eventually

#

I'mma just roll it up into maintaince

#

typos are great

#

C: maintenance I mean.

red sedge
bright glacier
#

I thought django was adopting black when it goes stable?

red sedge
#

No you're confused it's the other way around

bright glacier
#

Oh ok!

red sedge
#

This happened for Python 3 btw

silent spear
#

Hey, just posted a formatting question in #help-burrito regarding function declarations by #black-formatter and how I disagree with it if y'all are interested in discussing it. Understandable if not πŸ˜„

#

Sadly I don't have any concrete suggestions on how to make it better than it is now

flat krakenBOT
errant barn
#

Sharp words @drowsy sonnet!

drowsy sonnet
drowsy sonnet
#

Honestly, I really really want myself to be the last person who maintains support on EoL Python versions for an OSS thing in the ecosystem.

dense jungle
#

Do you maintain six?

drowsy sonnet
#

Nope.

#

I do wonder if the maintainer gets paid for it.

dense jungle
#

it's Benjamin Peterson I think?

drowsy sonnet
#

Yup.

drowsy sonnet
drowsy sonnet
bright glacier
#

I found that via the post about dropping python 2.6 support

drowsy sonnet
#

:)

red sedge
#

modernize still supports Python 2.7 as input

drowsy sonnet
#

For now. ;)

red sedge
lament crow
#

maybe a promise :)

drowsy sonnet
bright glacier
#

Progress is being made with blackbench!

Screenshot_from_2021-07-23_17-01-33.png
flat krakenBOT
#
glandium
[psf/black] Issue opened: #2395 Black is not consistent wrt trailing commas in argument lists

Describe the bug

Running black before and after modifying a file doesn't produce the same formatting wrt trailing commas in argument lists.

To Reproduce

<!-- Steps to reproduce the behavior:

  1. Take this file https://hg.mozilla.org/mozilla-central/file/287995cabe8ebd9a29f2f56dde65a84678a38229/testing/mach_commands.py
  2. Run Black on it, it makes no change (double checked after an upgrade to 21.7b0).
  3. Apply the following patch:
@@ -683,7 +683,10 @@ class SpiderM...
bright glacier
#

For blackbench I have the following to-dos before I'll be releasing 21.7.dev2:

  • Add metadata to the pyperf JSON results
  • Print out the version of black being tested
  • Significantly overhaul the documentation's content
#

Hopefully they don't take me too long (2 is literally a extra print statement, how hard could it be?).

dense jungle
# drowsy sonnet https://github.com/psf/black/issues/2156 -- so... how can I help with this?

There is a pull request for it, but Lukasz's comment here is pretty concerning: https://github.com/psf/black/pull/2237#issuecomment-850861722

GitHub
Keep user inserted optional parentheses by cdce8p Β· Pull Request #2...

This is the followup to #2163 as it was seen as a noticeable improvement but rejected due to the large impact on existing codebases.
With this PR, black will now keep user-inserted optional parenth...

bright glacier
#

Once 21.7.dev2 is released, I would be open to people actually exploring and using it (the docs aren't great right now so that's my main reason to holdback).

red sedge
#

the magic comma and proposed magic parentheses violate the "don't make me think" principal of black

red sedge
bright glacier
#

Actually, nevermind, it seems to be working now (even though it hasn't had an update since Dec 2020 ...)

bright glacier
#

Ugh, gotta love writing smoke tests that aren't actually testing anything when you refactored the test suite 18 days ago.

#

I have no idea why my smoke test is broken :/

#

OH I see

#

So the test was completely ignoring the code I was trying to pass to it run and check because I misconfigured it (I did not bork the assertion logic as I previously assumed).

#

And that explains why the smoke tests were suspiciously fast ... ahhhhhhh

#

hmm, I'm considering to use technically internal APIs in my test suite

#

it's probably fine, other than then being a bad user, but like whatever, I'm a maintainer so it shouldn't be too bad

#

also blackbench already depends on internal APIs for production use soo whatever

#

So yeah, I "fixed" the performance issue caused by actually testing what I intended to test by using internal APIs

#

Subprocess calls are expensive man.

late dewBOT
#

tests/smoke_tests.py lines 29 to 40

@pytest.mark.parametrize("target", resources.targets.values(), ids=lambda t: t.name)
def test_provided_targets(tmp_result: Path, run_cmd, target: Target):
    # This is basically what the `​fmt`​ task does, but without the huge subprocess overhead from
    # `​blackbench.run_suite`​. It's not perfect, but smoke tests should be fast afterall. Oh and
    # don't @ me about internal APIs and whatnot, it's fine (take it from a maintainer of black
    # :P). Although seriously please try to avoid using Black's internal APIs as much as possible
    # because their external usages makes maintenance harder :/
    code = target.path.read_text("utf8")
    try:
        black.format_file_contents(code, fast=False, mode=black.Mode())
    except black.NothingChanged:
        pass```
drowsy sonnet
drowsy sonnet
drowsy sonnet
drowsy sonnet
red sedge
#

Github refined is pretty good

drowsy sonnet
#

Another why-did-it-do-that formatting question!

                for installed_file in dist.get_metadata(
                        'installed-files.txt').splitlines():

Got changed to:

                for installed_file in dist.get_metadata(
                    "installed-files.txt"
                ).splitlines():

Neither is good, and... well, IDK what black should do -- but why did it do what it did?

red sedge
#

Single quotes?

drowsy sonnet
#

The reflowing.

red sedge
#

Right

#

Can you link to it in context? On GitHub?

drowsy sonnet
#

Gimme a few moments. It's from a PR I'm still writing the first commit of. :)

red sedge
#

It's very deeply nested it seems

#

And also I'm used to black I guess, because it looks mostly fine

red sedge
#

Black could wait until Monday evenings to release formatting changes, then everyone will have a full week to review the changes before autoupdatte day

stuck vapor
red sedge
#

@drowsy sonnet while pinning helps, there needs to be a way to communicate the expected black version to black, as I use it in my editor and elsewhere so version mismatches cause me the most pain

#

If there were some way black could detect that a different version of black is being used in a project it could then abort and recommend the correct version

#

Eg the encode community projects all have different versions of black configured

errant barn
#

There is one way! We have a required version configuration. That could be stored in pyproject for example

drowsy sonnet
drowsy sonnet
red sedge
#

And fell back to tool.black

lament crow
#

does anything other than flit support pep 621 right now?

#

that's not to say that I don't think it's a good idea, just wondering how many users would be able to benefit from it if it were implemented right now

red sedge
#

Gotta start somewhere

#

Django and requests were king makers for Python 3 imho

mint barn
#

@jolly reef

errant barn
bright glacier
#

My guess is that graingert means the target-version is automatically set from [project].requires-python?

#

I have no clue

lament crow
#

probably from project's dev dependencies

bright glacier
#

Oh yeah, that would require searching all of the extras (since dev is just one of the many names people use), it wouldn't even catch the dev-requirements.txt. Feels like a lot of work for too little gain, also sounds magical πŸ™‚

red sedge
#

No I mean the version of black needed

lament crow
#

ye, but it would be about supporting only pep 621

#

not any other ways of defining dependencies

red sedge
#

Like ```
[tox]
minversion=3.12

bright glacier
#

But how does this interact with PEP 621 project metadata?

lament crow
#

are you sure you mentioned the right pep then?

red sedge
#

Or pytest minversion

errant barn
#

we have

[tool.black]
required-version = 21.b1
#

or whatever the versions are :D

red sedge
#

Oh already?

errant barn
#

Yep!

bright glacier
#

Indeed

red sedge
#

TIL

errant barn
#

You're welcome ;)

lament crow
#

oh lol

red sedge
#

That would save me some pain if people implemented it xD

bright glacier
#

Hopefully no one asks for range support (I'd probably reject it) πŸ˜„

lament crow
#

I was confused because you responded to felix mentioning the required version thingie

#

and mentioned pep 621 rather than pep 517 :)

red sedge
bright glacier
#

Originally the PEP wanted people to not put tool configuration in pyproject.toml but clearly that didn't happen πŸ˜„

lament crow
#

ye okay, nvm

red sedge
#

Black could read the required-version from

[project]
dependencies = ["black==21.b7"]
bright glacier
#

so??

[project.optional-dependencies]
dev = ["black == 21.7b0"]

means

[tool.black]
required-version = "21.7b0"
red sedge
#

Right

lament crow
#

hmm, does anyone else think that finding configuration options for black in its docs is now harder than it used to?

red sedge
#

My usual process for finding them is complaining they don't exist until someone tells me they already do

bright glacier
#

Would an index help?

lament crow
#

I'm guessing it's because you guys are hiding it now

unknown.png
errant barn
#

The CMD output is a bit hard to spot yeah

bright glacier
#

We can get rid of the dropdown

#

it's just one big codeblock so that was my original concern πŸ˜‰

lament crow
#

it's hard to notice if you just want to quickly find the right configuration options

#

and scroll fast through it

errant barn
#

I wonder if there would be an equivalent to sphinx-argparse for Click

lament crow
#

I think there might be something

errant barn
#

for generating a cleaner, indexable doc

lament crow
bright glacier
#

Should that be its own page then?

errant barn
#

well slap me sideways, that was quick

bright glacier
#

or is putting within the page still fine?

#

for context, people are (rightfully) saying that we should merge all of the usage and configuration pages into one

lament crow
#

For me it was obvious that I'll find the config options in the "Usage and Configuration" page, I just was unable to spot where the options are once I opened it.

#

so I don't really mind if it's just long cli output or sectioned list of options

#

I think it would probably be nicer if it were a sectioned list of options but that's more effort

errant barn
#

Or if we don't want to merge right now, maybe we could have another page right at the beginning: "CLI reference" or something like that

bright glacier
#

Alright, I'll look into sphinx-click then (TIL hopefully it works well)

lament crow
#

not sure how well sphinx-click works

#

never used it

bright glacier
#

The thing is that I really hate super duper long pages because it feels overwhelming

#

I like to be filter out the majority of the content by just skimming the headers

lament crow
#

personally I just would appreciate some Table of Contents with a list of all options/flags so that I can jump right to the one I'm looking for

bright glacier
#

(to be clear this isn't a point against using sphinx-click, I am more talking about the general issue about the structure)

#

there's some issue on the tracker about it

errant barn
#

Sow how about the "CLI reference" page then?

bright glacier
#

Since it's autogenerated I wouldn't mind

errant barn
#

At least for now (permanently)

#

yep

bright glacier
#

if it was not autogenerated, it would be a maintenance nightmare

#

I still need to get to the documentation again, there's a lot of improvements to be made sigh

lament crow
#

"CLI reference" doesn't immediately jump out as a place where I would find how to configure black with a configuration file

bright glacier
#

oh yeah that sounds not great

#

(if you can't tell, I'm only like half-interested, I need to think about this more critically later)

#

I have too many projects on the go for black πŸ˜…

#

I'mma open an issue about sphinx-click tho

lament crow
#

I'm not sure I entirely like how isort is doing it (might partially be because it's a lot more configurable than black which results in a very long list of options), but it does make it clear what is a config option in the file, what is the cli flag, what's the type of the config option (only needed for toml), and it describes the option nicely.
https://pycqa.github.io/isort/docs/configuration/options.html

#

and it's all listed in one place which makes it easy to search

bright glacier
#

I find their descriptions to be lacking a fair bit

#

In general, the documentation right now is more geared towards newer users, which wasn't really my main goal, but it shows. The README was massive but once learned, it was basically the easiest index-like page - and therefore really easy to use as a quick reference

lament crow
#

as a returning user, I'm definitely not going to drop black because of annoying documentation which realistically I will look at very rarely so it makes sense to make it more appealing to new users who you would want to attract

bright glacier
#

there is an argument to be said that we already have a lot of users, soo maybe not ticking off the existing userbase would be better?

#

Maybe better naming of the pages would help

#

in hindsight the basics is not great

#

While it's accurate, it's useless if you're looking for something specific (unless you want to remember all of the weird ways things are named)

lament crow
#

oh, I didn't notice the basics is its own page under usage and configuration

#

thought it's just all usage and configuration

#

I didn't really struggle with finding the right page though, I just struggled with finding stuff on that page

#

which did make me wonder if I'm on the right page though lol

bright glacier
#

People complained the docs now take too many clicks

#

which tbh I agree, just not sure how to fix it

flat krakenBOT
lament crow
#

perhaps "The basics" should just be the "Usage and Configuration" and the other documents should be in a different place

#

that would just require one click to get to the place you're looking for, assuming that you would get rid of the collapsible thingie

bright glacier
#

I just don't want to put too much stuff top-level again

#

for example it's unclear where blackd docs would go

#

Hmm, I'm starting to warm up to the idea of merging most of the usage and configuration content

#

sadly it's blackd that's an issue

#

This is also a lot of churn and I hate it

bright glacier
#

It's basically a whole another tool that has its own little usage and configuration docs so that makes it hard to just add to rest of black's usage docs

lament crow
#

Not really. I want to say it could be top-level but it doesn't seem to fit it that well... "Integrations" kinda makes sense but when you look at actual documents in it, it doesn't make as much sense so I don't know

bright glacier
#

black-primer was fine since it's developer facing so hiding it under contributing was good enough

#

huh

#

the only other idea I had was putting blackd somewhere under guides

#

but that still doesn't make much sense

dense jungle
#

I feel like it makes sense under integrations because it's a tool for integrating black with your needs

lament crow
#

I feel Integrations still makes the most sense even though unlike the most things there, blackd is suited more for developers that want to integrate some thing (i.e. editor) with Black rather than end user who wants to integrate a tool they use with it

#

"Guides" is a scope creep kinda

bright glacier
#

Yeah, although making blackd more user-friendly is an open idea

#

also, yeah my guides idea is dumb

#

let's ignore that

#

Although, blackd has been very stable and untouched these days so it changes down the road, dealing with the docs issue then is probably fine. I think I'm getting too caught up with longterm planning

lament crow
bright glacier
#

OK, in summary in terms of structural changes:

  • merge the usage and configuration content into one page
  • move blackd to intergrations
  • possibly change a few headers to be more descriptive
#

that sounds OK to me - will need a fair bit of redirects though to avoid so much churn

lament crow
#

do you guys use RTD redirects?

bright glacier
#

We don't have any configured right now but I have RTD access so I can

#

I'm happy we stopped using GitHub as a secondary documentation host because redirects aren't really possible πŸ™‚

#

I guess another documentation thing that is worth discussion is the HTML theme

lament crow
#

furo time? 😏

bright glacier
#

it's fine (and the proposed changes above don't clash with Alabaster) right now but mobile support is ... garbage

bright glacier
#

My main concern is it seems like Black is going for a more old styling? Like its logo is the Ford logo, the name is literal reference from many many years ago ... and ReadTheDocs / Furo are pretty modern in their design

lament crow
bright glacier
lament crow
#

yep!

bright glacier
lament crow
#

also by Pradyun

bright glacier
#

I honestly don't understand why Alabaster is still the default Sphinx theme when mobile support is so big these days

#

I guess Python is still desktop focused so that's why.

red sedge
bright glacier
#

You're the third person to mention that theme so yes, it is indeed hot πŸ™‚

lament crow
#

I have my issues with it but it's generally awesome

#

mostly because I've been trying to apply it to a project with a rather big documentation

bright glacier
#

I personally find it a little frustrating when using on my laptop since the right sidebar TOC is hidden

lament crow
#

works great for a smaller documentation I've been working on recently

bright glacier
#

although I fixed that by hiding my OS side task bar

bright glacier
lament crow
#

mine is devguide-like documentation for a project I'm maintaining but I can't really link a full documentation as it's still all WIP with a bunch of PRs that each add different documents πŸ˜„

#

documenting and improving triaging process is fun...

bright glacier
#

haha can be annoying, maintainer docs are underratted tho!

lament crow
#

yeah, there's so much stuff that maintainers do that isn't documented properly, making it rather dangerous if anything were to happen with those maintainers

bright glacier
#

Indeed, for example Łukasz isn't that active anymore but there was a time where only he knew the release process

#

that was one of the many reasons why we didn't release for so long

lament crow
#

ye, I recently pretty much documented the whole release process, probably will have to automate it a bit further (though it is a already automated, just could be a bit more :))

bright glacier
#

We still depend on him for some admin stuff (he's the only admin on the repo) but in general we do just fine without his involvement (thanks to the 8 excluding-him person team we got)

#

I mean, in reality it's only really like 4 people who are consistently active, but that's still way better than a LOT of projects

bright glacier
lament crow
#

I enjoy automating stuff πŸ˜„

#

sometimes I probably overengineer though

bright glacier
#

I recently automated a wheel building workflow and while there was a ton of head scratching (mostly at C buildchain stuff) it was indeed fun

bright glacier
#

I bet for flit it's probably just "install flit and run flit publish", hopefully 🀞

lament crow
#

I recently made the release workflow depend on the GitHub environment (so that I need to approve the run) after accidentally releasing from a wrong branch (which fortunately, did not contain any major changes, just resulted in an incomplete changelog)

bright glacier
#

I might play with that

#

Somehow I failed to switch Black's docs to Furo locally

Screenshot_from_2021-07-24_14-26-13.png
#

I did remove a bunch of theme configuration without much thought, but it shouldn't be that broken?

lament crow
#

this is what I've done basically to minimise human errors lol

jobs:
  release_information:
    if: github.repository == 'Cog-Creators/Red-DiscordBot'
    name: GO HERE BEFORE APPROVING
    runs-on: ubuntu-latest
    steps:
      # Print release information
      - name: REVIEW OUTPUT OF THIS STEP BEFORE APPROVING
        env:
          TAG_BASE_BRANCH: ${{ github.event.base_ref }}
          TAG_REF_NAME: ${{ github.ref }}
          RELEASE_VERSION: ${{ steps.version_to_release.outputs.version }}
        run: |
          echo 'Release information:'
          echo "- Branch the tag was based off: ${TAG_BASE_BRANCH#'refs/heads/'}"
          echo "- Tag name: ${TAG_REF_NAME#'refs/tags/'}"
          echo "- Release version: $RELEASE_VERSION"

  release_to_pypi:
    needs: release_information
    environment: Release
    name: Release to PyPI
    # ...
red sedge
#

I wish pypi did staged releases

bright glacier
#

I don't understand why this html is so broken

red sedge
#

So you could upload it then approve it in the gui

lament crow
#

but no funding

bright glacier
#

yeah staged releases would be nice, sounds like money would have to be involved to get it done tho (unless there's an open PR for it already?)

lament crow
#

hmm, perhaps there was even a PR πŸ€” or maybe it was some other warehouse issue...

#

ah

#

I guess no funding was about some other issue I was looking at then

bright glacier
#

I don't remember what was the difference between draft vs staged releases, if there's any beyond naming

lament crow
#

though I don't think this one has funding either

bright glacier
#

I'm going to try building a new environment from stratch, the theme clearly applied since the "built with the furo theme" line was added but the styles are very borked

#

what's weird is that there's no errors or warnings from sphinx

lament crow
# bright glacier I don't remember what was the difference between draft vs staged releases, if th...

Right now, there are ways for package maintainers to test and share
draft versions of their upcoming releases, but they cause friction and
confusion. So we want to add staged releases -- a temporary state that a
release can be in, where PyPI has it and can evaluate it, but hasn't
published it yet.

We have also variously called this idea "unpublished releases",
"two-phase upload", "draft releases", and "package preview". This
feature will unblock a LOT of stuff we want to do -- see
https://wiki.python.org/psf/Fundable Packaging Improvements#Package_preview_feature_for_PyPI
for a list.

#

I guess it's the same then

bright glacier
#

I'm eagerly waiting for the static distribution metadata pep to be accepted and then implemented, it should cut down resolving times significantly

lament crow
#

is it beneficial to pipenv or what is it about

bright glacier
#

So OK currently to get distribution metadata (so for example you could check for compatibility with the rest of the dependency tree) you need to pull down the whole wheel

#

which is wasteful if you're going to end up rejecting it

#

Sorry, I wasn't clear that the PEP I was referencing was about indexes, not some package metadata standard

lament crow
#

googling told me it's about pypi serving this in its api, just was wondering if there was a party that would benefit from it the most (mostly because I recall something about pipenv or some other popular project needing more data in api to not be as slow as it is right now)

#

I guess any dependency resolver will benefit from it then

dense jungle
#

I believe it'd be useful for pip. The pip resolver needs to know information about many versions of packages you request

lament crow
#

there's so many PEPs that it's easy to get them confused πŸ˜„

dense jungle
#

But right now it has to download the whole wheel to get metadata like dependency versions

bright glacier
#

Finally, I got the black docs to build with furo

#

So one thing that's painfully obvious is that logo PNG isn't transparent

#

there's this ugly white background

errant barn
#

it's fine on github though..

unknown.png
#

it might be the other file then!

bright glacier
#

Oh for some reason there's two PNGs

errant barn
#

ye

bright glacier
#

Oh yeah another plus of not using alabaster is that we get to get rid of the custom CSS I wrote πŸ˜„

#

surprisingly the CSS has not broken even though I'm no web dev

#

Anyway, time to write down the results of all of this discussion on the various related issues.

#

This Discord channel has been really useful for real-time communication lemme say! Discussions are 10 times easier here πŸ™‚

dull olive
bright glacier
#

Basically anyone who needs to collect massive amounts of distribution metadata will benefit (that includes all dependency resolvers at least).

dull olive
bright glacier
# drowsy sonnet I use Refined GitHub; and I'd highly recommend it.

Whelp, I avoided using this extension because I felt like all of the many changes it makes would feel overwhelming but after some initial tweaking, it's pretty good! I'll probably need to disable quite a few more things but that's okay :) Thanks for nudging me to finally use it! ... although I still don't see a file tree for PRs :/

lament crow
#

Refined GitHub doesn't provide a file tree for PRs

#

but please do use Refined GitHub :)

#

it's awesome

#

The one feature that you might want to be aware of is pr-branch-auto-delete, I think it's the only one that introduces surprising behavior

bright glacier
#

Apparently it's loading twice everywhere which isn't great

lament crow
#

huh?

bright glacier
#

nothing seems to be broken other the home page activity box (but it's not a big deal)

# 
refined-github.js:1924 
Refined GitHub has been loaded twice. This may be because:

β€’ You loaded the developer version, or
β€’ The extension just updated

If you see this at every load, please open an issue mentioning the browser you're using and the URL where this appears.
lament crow
bright glacier
#

wait what

lament crow
#

hide-useless-newsfeed-events, hide-own-stars

bright glacier
#

eh, I like how they fill the space

lament crow
#

then you can disable it :P

bright glacier
#

not useful by any means, but πŸ˜›

lament crow
#

that's the beauty of it

#

there's even a nice bisect feature that allows you to find out which feature is making some change you don't like

bright glacier
#

Oh wow, I'm just using luck + the debug logs

lament crow
frozen badge
#

bisect should be in everything tbh, vscode has it for extensions which is the first time ive seen it

lament crow
#

perhaps a browser restart will help

#

if not then you might want to report it indeed

bright glacier
#

It seems to have disappeared after a restart πŸ˜„

flat krakenBOT
#
ichard26
[psf/black] Issue opened: #2397 Should we switch our Sphinx HTML theme away from Alabaster?

As far as I know, Black has stuck with the same old theme from day one. I'll admit it's nice and fits in nicely with the more rustic / old vibe the all of the branding has (eg. Ford-like logo, name based off quote that's quite old). Unfortunately there's a few hard-to-workaround issues:

  • Phones or really any devices with small screens are not supported at all
  • Due to limitations (ie. no scrolling support in the sidebar), there's custom CSS, see [/docs/_static/custom.css](https://githu...
bright glacier
#

Oh and right as I click "post" it just hit me that I should include previews of the two other themes I mentioned

#

my thoughts are a mess :)

flat krakenBOT
bright glacier
#

@dense jungle, are you sure Furo uses "+" for expanding the sections?

Screenshot_from_2021-07-24_18-54-36.png
#

I'm just a little confused by that

dense jungle
#

Oops I swapped the two

#

Let me edit my comment

#

Sorry for that. I guess I opened the two tabs and then forgot which is which

bright glacier
#

Don't worry, just wanna to let you know to avoid confusion πŸ™‚

flat krakenBOT
dense jungle
#

I like the headings within a page better in RTD though.

Screen_Shot_2021-07-24_at_3.58.47_PM.png
flat krakenBOT
bright glacier
#

Yeah the font of furo is quite basic, definitely less pleasant on the eyes even if I know readability was the reason why

dense jungle
#

But ultimately I think you should make the call as our informal docs owner :). I can talk about what looks better to me but that's all subjective

bright glacier
#

"JelleZijlstra-patch-1" I love this branch name πŸ˜„

dense jungle
#

that's just the default when you edit from the web UI. I was pretty proud of myself for writing prettier-clean docs in the web UI πŸ™‚

bright glacier
#

You almost fooled me into thinking you made a patch from your fork.

bright glacier
#

oh wait that was your comment

#

🀦

#

Eventually one develops the ability to wrap a commit message properly to roughly 72 characters without a guideline in the GH merge box πŸ™‚

frozen badge
#

honest question: does it matter much?

dense jungle
#

line wrapping in commit messages you mean?

frozen badge
#

yep

bright glacier
#

eh maybe, it does keep text closer together (I always expand my terminal windows so it isn't a problem per se) just visually nice

frozen badge
#

hm, isnt the fact that 72 chars is pretty outdated the exact reason black uses more (88 iirc)?

bright glacier
#

Part of me wants to argue these two line lengths are different due to context, but I have nothing :)

frozen badge
#

aw sad winning by default is no fun mmLol

bright glacier
#

I'm no fan of pointless arguments :-)

dense jungle
#

The docstrings PEP does say that strings should be wrapped at 72 characters I believe

bright glacier
#

... and there's a certain issue on the issue tracker related to that.

errant barn
#

psf/black#2289

toxic stormBOT
flat krakenBOT
lament crow
#

GH will not show full commit header if it takes more than 72, and terminal has a standard 80x24 size

flat krakenBOT
lament crow
#

I would say that GH and other tools cutting it is bigger issue than it getting wrapped in terminal but I guess it could also screw up the view in something like a oneline git log

lament crow
#

about this one

#

there's issue forms now

#

they're in public beta right now

bright glacier
#

Yeah I don't think we are part of that beta right now

lament crow
#

it's public beta

#

available on all repos

#

used to be private beta

bright glacier
#

D'oh, did not know that.

#

Please stop with the self-promotion.

lament crow
#

I'm not familiar with the etiquette in this server, do I just ping a random online mod to report these?

dense jungle
#

there's a partners channel that we have access to, @bright glacier already reported this person

#

I think you can DM @digital pilot ?

bright glacier
#

Yeah, not sure if that's less / more urgent but I've used the private channel we have access to before so eh

glacial gate
#

Otherwise you can also DM ModMail as mentioned

lament crow
bright glacier
#

I reported them too :)

dense jungle
bright glacier
#

That's one way of beating out the competition I suppose?

flat krakenBOT
drowsy sonnet
drowsy sonnet
drowsy sonnet
red sedge
#

I really hate it when docs override the system font

#

it just makes me punch the article mode button

flat krakenBOT
#
harryghgim
[psf/black] Issue opened: #2401 blackargs not recognized when using with \.editorconfig

Describe the bug
max line length formatting not applying when I use editorconfig. It applys only when I use vscode setting with black args --line-length=119. Please guide me if I missed anything.

To Reproduce

  • install editorconfig for vscode plugin
  • paste the following .editorconfig file recommended by django github
# https://editorconfig.org/

root = true

[*]
indent_style = space
indent_size = 4
insert_final_newline = true
trim_trailing_whitespace = true
...
final hedge
#

Black is the only formatter for python I use, it's rly good

lament crow
neon loom
bright glacier
#

It's probably the more of the domain of isort (their config afterall) but it is arguable that a "black" profile means it follows the spirit of black too and not just behaviour

dense jungle
#

I feel like that's an isort thing. I don't know what force_single_line dooes for example

bright glacier
#

Basically forces every from import to use their own lines

dense jungle
#

I don't like that πŸ™‚

#

too repetitive to read

#

but I think isort should make that decision

bright glacier
#

Yeah, hopefully not too many people think it's actually what black does (if it's even accepted).

red sedge
#

Urgh just make a choice and force it on me

#

Don't make me think

bright glacier
#

I don't know whether I'm misusing scalene or something like that, but this doesn't look right :/

Screenshot_from_2021-07-25_22-07-39.png
#

That's the result of profiling basically lib2to3_parse on src/black/trans.py

#

I highly doubt regex matching is actually taking 90%+ of the time

bright glacier
#

I don't have that much experience with C but actually poking into the generated C isn't that scary πŸ™‚ I just found a difference when adding Final to a function local variable:

 CPyL414: ;
-    cpy_r_r533 = ((blib2to3___pgen2___tokenize___generate_tokens_envObject *)cpy_r_r0)->_numchars;
-    if (unlikely(((blib2to3___pgen2___tokenize___generate_tokens_envObject *)cpy_r_r0)->_numchars == NULL)) {
-        PyErr_SetString(PyExc_AttributeError, "attribute 'numchars' of 'generate_tokens_env' undefined");
-    } else {
-        CPy_INCREF(((blib2to3___pgen2___tokenize___generate_tokens_envObject *)cpy_r_r0)->_numchars);
-    }
-    if (unlikely(cpy_r_r533 == NULL)) {
-        CPy_AddTraceback("src/blib2to3/pgen2/tokenize.py", "generate_tokens", 559, CPyStatic_globals);
-        goto CPyL1132;
-    }
-CPyL415: ;
+    cpy_r_r533 = CPyStatics[46]; /* '0123456789' */
     cpy_r_r534 = PySequence_Contains(cpy_r_r533, cpy_r_r532);
-    CPy_DecRef(cpy_r_r533);
     CPy_DecRef(cpy_r_r532);
     cpy_r_r535 = cpy_r_r534 >= 0;
     if (unlikely(!cpy_r_r535)) {
         CPy_AddTraceback("src/blib2to3/pgen2/tokenize.py", "generate_tokens", 559, CPyStatic_globals);
-        goto CPyL1025;
+        goto CPyL1024;
     }

That's some early binding right there πŸ˜„

#

Now there's a LOT of generated C code so it's definitely way more than I can handle but this is cool and fun (even if it may or may not help me optimize)

mint barn
#

Hello

#

Can someone help me here

errant barn
#

Sure, what's up?

mint barn
#

Why does that keep happening

#

Why does that keep happening

errant barn
#

This is probably not Black related, so in the future you might be better off asking in the dedicated help channels. But if you want to create the project, PyCharm simply warns you that you already have files there. No worries in pressing "Create from existing"!

flat krakenBOT
mint barn
#

can black format docstrings?

dense jungle
#

It makes some changes to docstrings, yes

mint barn
#

does it wrap docstrings to certain length?

bright glacier
#

whelp, I just tried to fix my touchpad not selecting text on click and drag but I ended up making things worse by installing a new driver so .. I uninstalled it

#

what's weird is that it's inconsistently not working

#

kinda a pain to deal with whole writing the docs for blackbench

#

Hmmm I wonder if it's a hardware issue since it seems to work if I press hard enough

tribal thistle
#

Could it be hardware?

#

Ah yis

bright glacier
#

Woo! I finished the last to-do item for blackbench 21.7.dev2 which was significantly overhauling the documentation. Now for the fun bit of tagging and pushing the release πŸŽ‰ (which will have to wait for tomorrow since funnily enough, I'm now busy again :P)

red sedge
#

Will black drop support for running on Python 3.6 before January? (Eg due to the December EOL of python 3.6)

errant barn
#

Most likely not. While we are discussing dropping it when the EOL happens, that might not even happen.

flat krakenBOT
#
michaelmiscanuk
[psf/black] Issue opened: #2402 Nested Tuples are not well formatted

I have some nested tuples, but unfortunately one of them is not well formatted with black.

First one is formatted well but look at the second one - BOOK_CHOICES.
Can you explain why is that happening?


RADIO_CHOICES = (
    ("Value One", "Value One Display"),
    ("Value Two", "Text For Value Two"),
    ("Value Three", "Value Three's Display Text"),
)

BOOK_CHOICES = (
    (
        "Non-Fiction",
        (("1", "Deep Learning with Keras"), ("2", "Web Development with D...
flat krakenBOT
#
buddhhu
[psf/black] Issue opened: #2403 AST error

Getting failed to parse source file. AST error message: expression cannot contain assignment, perhaps you meant "=="? (, line 73) even if there is no error.

The code is

async def download_episode(download_url):
    anime_name = name_parser(download_url)
    filename = anime_name + download_url[-4:]
    make_directory(anime_name)
    download_path = os.path.join(anime_name, filename)
    if not os.path.exists(download_path):
        await (
            await asyncio.cr...
dense jungle
#

^ I tried this yesterday when they posted in a different issue and couldn't reproduce it. Maybe someone else can extract a reproducible bug from it

tribal thistle
#

Failed to repro as well with what they posted

flat krakenBOT
red sedge
#

To be fair that would be convenient

#

I'm guessing something that gives you the changes interactively

#

And asks you yes or no to apply them

dense jungle
#

That sounds a lot less simple than the current CLI πŸ™‚

red sedge
#

Right?!

flat krakenBOT
bright glacier
#

Whelp, looks like someone already implemented the "blackd client utility" idea I was kicking around πŸ˜„

bright glacier
bright glacier
#

Oh I managed to mess up the pyperf requirement, I thought pyperf~=2.0.0 would've worked but apparently not

teal goblet
#

I wish the blackconnect pycharm plugin would automatically start its own instance of blackd.

tribal thistle
#

I’d offer to help make a new plugin, but god jetbrains plug-in creation is possibly the worst thing I’ve done in my life

#

Great products, just never try to make plug-ins lol

teal goblet
#

I ended up just making a file watcher to run black

bright glacier
#

So for some reason my system is consistently inconsistent, like every 3rd process is slower than all of the rest. I tuned my system as well as I can with my knowledge so oh well :P

#

I'm just checking whether my optimizations are actually making a difference

#

Whelp, overall 5% faster on parsing, that's better than nothing but it's lower than I would've hoped

#

More work to be done I suppose πŸ™‚

red sedge
#

@bright glacier have you seen the celery entry point layout? They recently collapsed all their entry points into one

bright glacier
#

No I have not, I'm assuming you're implying it was a bad change?

#

I haven't used celery before actually, so I don't have any context to determine how good of a change that would be.

plain atlas
#

wut

#

how to set black to not sort imports?

#

accorrding to this, its not supposed to sort imports, or did this change?

bright glacier
#

I'm -1 on the proposal but I know Jelle is at least on the positive side

dense jungle
#

Right now it definitely doesn't sort imports. If you're seeing imports being sorted, it's some other tool

red sedge
bright glacier
#

I'm curious, how many entry points did they have?

red sedge
#

I'm not actually sure

#

celery-beat celery-multi celery-worker

#

And some others too

bright glacier
#

Ah, black currently has three, black, blackd, and black-primer (this one is a tool for developers of black)

plain atlas
#

ah

dense jungle
#

isort is more likely to be the one sorting imports. to get it to produce output compatible with black you can use a custom profile, it's mentioned in the black docs

plain atlas
#

its a line length somewhere

#

so

#

the pre-commit hook for black should read from pyproject.toml?

#

its isort somehow

bright glacier
#

I have no idea what's different but today has been a whole heck of a smoother experience optimizing black (sorry I mean blib2to3) for mypyc πŸ˜›

Screenshot_from_2021-07-27_18-29-50.png
plain atlas
#

Finally fixed isort

#

Can indirectly blame Joe because I copied the config from a pydis project but it was wrong in pydis :))

delicate marsh
#

😎

flat krakenBOT
plain atlas
smoky gyro
#

Hi all. I am new to using black formatter. Is there a way to set max-line-length constraint for a single file? And the remaining files can use the default constraint.

errant barn
#

Hi! Beyond the obvious answer of running Black twice with different arguments, there isn't. But I'm curious, why do you want that? πŸ˜„

smoky gyro
#

A friend of mine wants to increase line length constraint for a particular directory and I do not want that constraint to hamper the entire repo

#

running Black twice with different arguments
This is a good idea. Lemme try setting black precommit twice and see if this works

#

Thanks Felix

errant barn
#

My pleasure! Although I'd argue that if there is no specific reason other than preference, you might be better off reaching a consensus πŸ˜…

tribal thistle
#

Hmm it might be worth considering having directory specific configs. I can think of at least one situation where artificially raising the limit might be useful, specifically templates (think things like django templates)

errant barn
#

Fair point!

tribal thistle
#

By directory specific, I’m thinking it’ll use the closest config, working from the file, out

errant barn
#

Still needs two calls, but the configuration is much easier

tribal thistle
#

Oh, I was suggesting this as a feature request haha

errant barn
#

Oh πŸ˜„ I see, go ahead! It might well be worth discussing.

raw comet
#

this is nice project

flat krakenBOT
#
hugovk
[psf/black] Pull request opened: #2406 Test on Python 3\.10\-dev

Python 3.10 is currently in its last beta with a release candidate due next week (2021-08-02).

This PR tests 3.10-dev on GitHub Actions, currently Python 3.10.0-beta.4.

I put the versions in quotes in the yaml, because when 3.10 final is released and -dev is removed from 3.10-dev, quoteless 3.10 would evaluate to 3.1!

flat krakenBOT
austere lava
#

I'd be interested in this ^ for libcst testing

#

subscribed to the issue πŸ™‚

little parrot
#

Is black using libcst now?

dense jungle
#

no

#

we might in the future though

austere lava
#

I found the cpython test suite to be lacking in terms of exercising all the language features

#

they do a good job for all recently added features though

dense jungle
#

interesting, what are they missing?

austere lava
#

I'd probably want some more complex expressions and bodies for if and while πŸ™‚

#

semantic features are well covered, but the syntactic minutiae are just not there: optional brackets, commas, newlines, backslashes, semicolons, ...

#

they are probably covered in the tokenizer tests to some extent since that abstracts all of this away from PEG in CPython

#

but for the purposes of black/libcst/... these are important test cases

dense jungle
#

Right, makes sense

stuck vapor
#

Question about the Jupyter Notebook support PR - many of the handle_magics functions are duplicative of what's already in nbQA. Would it be alright to add nbQA as an optional dependency when running on Jupyter Notebooks, and import these magic handling functions from there?

Also, are there any generic concerns about adding Jupyter Notebook support?

dense jungle
#

Sorry I should get back to that PR but haven't had much time recently. I think we should land it but need to confirm all concerns are addresseed

#

As for adding a dependency, I'd be slightly hesitant to add more dependencies since they may also affect import performance. I haven't looked at nbQA though

woeful orbit
#

Hi

stuck vapor
red sedge
smoky gyro
bright glacier
#

I feel like I ended up re-implementing a variation of black-primer πŸ˜…

Screenshot_from_2021-07-29_16-10-24.png
#

I'm planning to use this to make sure there's no behavioral difference visible to end-users across a large swath of files between two invocations of Black (in my case interpreted vs compiled).

flat krakenBOT
bright glacier
#

Hmm, looks like mypyc transpiles black twice during a wheel build (on CI via cibuildwheel), that's unfortunate :/ I don't think it's avoidable since it seems like any setuptools PEP 517 hook ends up executing setup.py (and the transcompilation) and both pip wheel (cibuildwheel uses this) and python -m build calls at least two hooks (get_requires_for_build_wheel or prepare_metadata_for_build_wheel + build_wheel). Kinda sucks that analysis + transpilation to C takes a good while (15-30s). At least locally it's avoidable using python setup.py bdist_wheel.

flat krakenBOT
dense jungle
#

@bright glacier what do you think of landing this? ^

bright glacier
#

I'll take a look tomorrow (it's ~11 PM over here!) but unless there were significant changes recently I don't have any major concerns IIRC.

dense jungle
#

thanks!

flat krakenBOT
flat krakenBOT
#
complyue
[psf/black] Issue opened: #2409 Please honor intended \*horizontal\* grow with magic comma

Is your feature request related to a problem? Please describe.

https://github.com/psf/black/pull/826#issuecomment-493549892

... for collections that you know will grow, there was no way to anticipate it by exploding them into one-element-per-line. Why would you want that? Because it minimizes diffs and that is a thing Black advertises as a feature: minimizing diff noise.

Now with #826 effected, my short collections with trailing commas will all explode, introducing way too loud...

flat krakenBOT
neon loom
#

Aim for a Sunday release with notebooks support?

#

I'll be afk for 2 days but back Sunday afternoon.

dense jungle
#

sounds good

stuck vapor
neon loom
#

Sure thing. Thanks for all the work!

austere lava
#

I want more test cases like this πŸ™‚

lament crow
#

there are some syntax errors in there, should there be? πŸ€”

muted haven
dense jungle
lament crow
#

( x , *y , * z , ) = l

dense jungle
#

Oh I see, that produces SyntaxError: two starred expressions in assignment

lament crow
#

there can only be one starred expression in assignment and this is detected during syntax parsing

#

ye

austere lava
#

oh yeah there are 2-3 syntax error in there but they're parsed by the grammar

dense jungle
#

I guess that's the weird kind of syntax error that's produced outside the parser

austere lava
#

these syntax errors are emitted after pegen πŸ™‚

lament crow
#

ah

austere lava
#

thx!

muted haven
austere lava
#

it's going to be great to help me hunt down the missing 1% of the grammar and edge cases πŸ™‚

#

I'ma bout 70% there

#

on that tuple torture file the new parser is ~30x faster than libcst

bright glacier
#

Hmm I wonder if mypyc compiled blib2to3 is slower than the experimental rust-based parser πŸ˜›

austere lava
#

it's not a fair comparison yet πŸ™‚

bright glacier
#

Well yea ... I guess we'll see later then (I may or may not be currently optimizing blib2to3 for mypyc πŸ˜‰)

dense jungle
#

Yes, I started looking at the TOML issue too and it seemed like it was still under discussion

#

I'll watch it and follow whatever pip does

bright glacier
#

Exactly my thinking as well πŸ™‚

flat krakenBOT
bright glacier
#

tests/test_black.py:34: in <module>
import black
src/black/init.py:47: in <module>
from black.files import find_project_root, find_pyproject_toml, parse_pyproject_toml
bm-venv/lib/python3.8/site-packages/black/files.py:26: in <module>
from black.handle_ipynb_magics import jupyter_dependencies_are_installed
src/black/handle_ipynb_magics.py:316: in <module>
class CellMagicFinder(ast.NodeVisitor):
E AttributeError: attribute 'dict' of 'type' objects is not writable
I was scared of this happening with the dataclass + subclassing + mypyc πŸ˜”

#

dataclasses + subclasses has been the biggest compatibility pain-point with mypyc and looks like the jupyter PR makes this situation worse. I won't block on it, but yay for more work *sigh*

#

Well OK I found at least one maybe-blocking issue with the PR

# 
1❯ cat tests/data/notebook_no_trailing_newline.ipynb | black - --check --diff -l 50 -v --color
Using configuration from /home/ichard26/programming/oss/black/pyproject.toml.
--- STDIN    2021-07-30 19:21:30.173162 +0000
+++ STDOUT    2021-07-30 19:21:30.246786 +0000
@@ -1,39 +1,37 @@
 {
- "cells": [
-  {
-   "cell_type": "code",
-   "execution_count": null,
-   "metadata": {
-    "tags": []
-   },
-   "outputs": [],
-   "source": [
-    "%%time\n",
-    "\n",
-    "print('foo')"
-   ]
-  },
-  {
-   "cell_type": "code",
-   "execution_count": null,
-   "metadata": {},
-   "outputs": [],
-   "source": []
-  }
- ],
- "metadata": {
-  "interpreter": {
-   "hash": "e758f3098b5b55f4d87fe30bbdc1367f20f246b483f96267ee70e6c40cb185d8"
-  },
-  "kernelspec": {
-   "display_name": "Python 3.8.10 64-bit ('black': venv)",
-   "name": "python3"
-  },
-  "language_info": {
-   "name": "python",
-   "version": ""
-  }
- },
- "nbformat": 4,
- "nbformat_minor": 4
-}
\ No newline at end of file
+    "cells": [
+        {
+            "cell_type": "code",
+            "execution_count": null,
+            "metadata": {"tags": []},
+            "outputs": [],
+            "source": [
+                "%%time\n",
+                "\n",
+                "print('foo')",
+            ],
+        },
+        {
+            "cell_type": "code",
+            "execution_count": null,
+            "metadata": {},
+            "outputs": [],
+            "source": [],
+        },
+    ],
+    "metadata": {
+        "interpreter": {
+            "hash": "e758f3098b5b55f4d87fe30bbdc1367f20f246b483f96267ee70e6c40cb185d8"
+        },
+        "kernelspec": {
+            "display_name": "Python 3.8.10 64-bit ('black': venv)",
+            "name": "python3",
+        },
+        "language_info": {
+            "name": "python",
+            "version": "",
+        },
+    },
+    "nbformat": 4,
+    "nbformat_minor": 4,
+}
would reformat -
Oh no! πŸ’₯ πŸ’” πŸ’₯
1 file would be reformatted.
#

Diffs aren't handled correctly when piping in a jupyter notebook ... I'm not sure how Black knows it's a jupyter notebook but this should probably be handled in a better way

dense jungle
#

I think it's just reformatting it as Python lol

#

JSON is usually valid Python

bright glacier
#

oh lol

dense jungle
#

You can use the --ipynb option to force treating it as ipynb

bright glacier
#

IIRC that got removed because I complained that it's bad UX, I didn't mean to remove it, but I definitely wanted to address it eventually

#

I was complaining about how internally it would be confusing to represent is_pyi and is_ipynb separately in black.Mode. We should probably bring it back but make it an error to define both flags at once at the CLI level

#

But given that we have both verbose and quiet treated separated I guess this ship sailed already 🀷

bright glacier
#

@dense jungle thoughts? ^^

#

I'm close to finishing my review but I'm not fully decided on what to do about the above.

dense jungle
#

Honestly I feel like we should just add the option. If click supports mutually exclusive options we can use that, otherwise no big deal

bright glacier
#

Click does not, but it's fine to implement this manually

lament crow
#

I believe there are also some packages that extend click to support it

#

but might just be easier to implement it manually

bright glacier
#

100%, cloup is one I know of, but that's way more heavy handed then implementing it manually

lament crow
#

there's also click-option-group

#

I don't think I've heard of any other

flat krakenBOT
#
ichard26
[psf/black] Pull request review submitted: #2357 Jupyter notebook support

Overall it looks good to me, there's some possible cleaning up to do, but pretty all large PRs has deal with that. The only main change I'd like to see is to bring back the --ipynb flag, I thought about it some more and discussed it with Jelle and ended deciding / realizing that the ability to force ipynb mode is more important than the UX or internal representation (perhaps it will be fine in the end and it ends up just being a quirk of the codebase :slightly_smiling_face:). Sorry for back...

bright glacier
#

Alright, overall that PR LGTM, just suggested to bring back the --ipynb flag

dense jungle
#

I am trying hard now to think of a use case for putting type stubs in ipython notebooks πŸ˜„

bright glacier
#

Don't understand the point of it, but that's pretty typical I guess haha

dense jungle
#

spam or they just replied to the wrong email in their inbox or something

bright glacier
#

That's possible too. OT I got curious to what language the surrounding text seems to be, apparently Portuguese according to google translate .. the more you know

stuck vapor
bright glacier
# austere lava it's going to be great to help me hunt down the missing 1% of the grammar and ed...

Whelp, now I'm dealing with my own edge cases:

--- test2.py    2021-07-30 21:04:16.577111 +0000
+++ test2.py    2021-07-30 21:06:17.376117 +0000
@@ -1,7 +1,8 @@
-def func() -> ((also_super_long_type_annotation_that_may_cause_an_AST_related_crash_in_black(
-        this_shouldn_t_get_a_trailing_comma_too
-    ))
+def func() -> (
+    (
+        also_super_long_type_annotation_that_may_cause_an_AST_related_crash_in_black(
+            this_shouldn_t_get_a_trailing_comma_too
+        )
+    ),
 ):
     pass
-
-

Turns out the surrounding tree of the first body leaf can vary a lot (I should've saw this coming but didn't πŸ˜… ) making it a bit harder to figure out whether we're in a return annotation.

#

That case above ^^ isn't fixed by my original patch, currently working on (read: testing and trying to break) a better fix.

plain atlas
#

wtf

#

i know i mentioned that before but it never ceases to amaze me and idk why

bright glacier
#

Yeah we got a lot of CI

plain atlas
#

just a little.

#

most just

bright glacier
#

And that doesn't include our CD pipeline πŸ˜„

plain atlas
#

building on multiple devices and OSes

plain atlas
#

wait its missing a bunch of checks using 3.11-dev πŸ˜” /hj

bright glacier
#

currently it's build sdist + wheel & publish to pypi, build os native binaries + publish to gh releases, and build docker image and push to dockerhub

#

Eventually there might be a few more jobs for automatic mypyc compilation πŸ˜„

bright glacier
#

Although the docker one runs on every commit to main too IIRC

plain atlas
#

which is how it should be tbh

silent apex
bright glacier
#

Honestly I don't know, I barely use docker so Iemme find the relevant issue (it's probably something with having a static build of black all ready to go for end users)

silent apex
#

Can't people just do something like RUN python -m black . in their Dockerfile?

plain atlas
#

gtg

bright glacier
#

psf/black#1914

toxic stormBOT
silent apex
#

I still don't really get why they need a Dockefile for that instead of just installing it as a dep and running RUN python -m black . but I dunno

bright glacier
#

Me neither honestly :>

#

@stuck vapor I don't think this looks right:

~/programming/oss/black on jupyter [$?] via v3.8.5 (bm-venv) 
❯ cat tests/data/notebook_no_trailing_newline.ipynb | black - --check --diff -l 50 -v --color --ipynb
Using configuration from /home/ichard26/programming/oss/black/pyproject.toml.
--- STDIN    2021-07-30 21:23:14.558027 +0000
+++ STDOUT    2021-07-30 21:23:15.048800 +0000
@@ -8,11 +8,11 @@
    },
    "outputs": [],
    "source": [
     "%%time\n",
     "\n",
-    "print('foo')"
+    "print(\"foo\")"
    ]
   },
   {
    "cell_type": "code",
    "execution_count": null,
would reformat -
Oh no! πŸ’₯ πŸ’” πŸ’₯
1 file would be reformatted.

~/programming/oss/black on jupyter [$?] via v3.8.5 (bm-venv) took 947ms 
1❯ black tests/data/notebook_no_trailing_newline.ipynb  --check --diff -l 50 -v --color
Using configuration from /home/ichard26/programming/oss/black/pyproject.toml.
--- tests/data/notebook_no_trailing_newline.ipynb    2021-07-30 21:22:45.713550 +0000:cell_0
+++ tests/data/notebook_no_trailing_newline.ipynb    2021-07-30 21:23:26.889930 +0000:cell_0
@@ -1,3 +1,3 @@
 %%time
 
-print('foo')
+print("foo")
would reformat tests/data/notebook_no_trailing_newline.ipynb
Oh no! πŸ’₯ πŸ’” πŸ’₯
1 file would be reformatted.
#

I wonder if --code has the same behaviour ... but it seems unlikely someone would use that + --ipynb πŸ˜„

#

Well actually someone could technically argue that if someone is piping in a notebook with --diff then they will probably apply that diff so the current output is better (not really possible with the latter).

stuck vapor
bright glacier
#

So wait, which format are you proposing to change to, the one from piping or the one from a file?

#

I don't really care that much, just the inconsistency stuck out at me

stuck vapor
#

IMO, what you've shown above would be the best thing to display.

If you want though, I can change so that this happens:

$ cat tests/data/notebook_no_trailing_newline.ipynb | black - --check --diff -l 50 -v --color --ipynb
Using configuration from /home/marco/black-dev/pyproject.toml.
src -
--- STDIN       2021-07-30 21:38:15.609258 +0000:cell_0
+++ STDOUT      2021-07-30 21:38:15.758472 +0000:cell_0
@@ -1,3 +1,3 @@
 %%time
 
-print('foo')
+print("foo")
would reformat -
Oh no! πŸ’₯ πŸ’” πŸ’₯
1 file would be reformatted.
dense jungle
#

hm, I can see arguments for both sides. Is the point of diff mode so you can easily get a sense for what black changes, or is it a way to be able to save diffs that you can apply manually?

#

if the former, we'd want the python-only diff; if the latter, we'd want the JSON diff

#

Personally I just use it for getting a sense of changes, so I'd want the Python-only diff, but others may have different use cases

bright glacier
#

My gut says that a Python-only diff doesn't make much sense since a notebook is already not 100% python code (I hope I am getting this right) so you would look at changes via the rendered version. BUT I get the Python-only argument too 🀷

#

If the notebooks we're formatting are 100% python code then please ignore my statement πŸ™‚

stuck vapor
#

What would be the expected output if you were to run cat tests/data/notebook_no_trailing_newline.ipynb | black - -l 50 -v --color --ipynb? (i.e. the command you pasted above, but without the diff)

This would show the json output. So IMO if you pass --diff then still showing json output would be consistent with that

bright glacier
# 
❯ cat tests/data/notebook_no_trailing_newline.ipynb | black -   -l 50 -v --color --ipynb
Using configuration from /home/ichard26/programming/oss/black/pyproject.toml.
{
 "cells": [
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {
    "tags": []
   },
   "outputs": [],
   "source": [
    "%%time\n",
    "\n",
    "print(\"foo\")"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": []
  }
 ],
 "metadata": {
  "interpreter": {
   "hash": "e758f3098b5b55f4d87fe30bbdc1367f20f246b483f96267ee70e6c40cb185d8"
  },
  "kernelspec": {
   "display_name": "Python 3.8.10 64-bit ('black': venv)",
   "name": "python3"
  },
  "language_info": {
   "name": "python",
   "version": ""
  }
 },
 "nbformat": 4,
 "nbformat_minor": 4
}
reformatted -
All done! ✨ 🍰 ✨
1 file reformatted.
bright glacier
dense jungle
#

yes, sounds like JSON diffs make more sense

flat krakenBOT
bright glacier
#

Well the good news with that is that I don't have any comments left and will press the fancy green button πŸ˜„

little parrot
#

is there a way to allow top level await in black?

dense jungle
little parrot
#

i guess ill just have to wait to blacken my docs then

#

πŸ‘

bright glacier
#

Hmm, blackbench currently heavily assumes that the only input used during benchmarking is Python code. Once jupyter notebook support is landed, that's going to be a problem if we ever want to add a benchmark for it. I was trying to avoid this, but maybe generic benchmark (on top of the specialized and first-class support for task+target based benchmarks) support should be implemented ... I'll have to think about this.

#

While adding support for it in the backend should be quite easy, the CLI would need a rewrite since the entire core concepts of blackbench would be changed (not to mention docs and tests).

#

Love how I thought of this issue at midnight /s ... I guess it's better than never πŸ™‚

plain atlas
stuck vapor
bright glacier
#

oh it's definitively on blackbench's side

bright glacier
#

So one thing that hasn't been clear is how my mypyc work will end up integrated (take it as take you'd like). Currently I'm working on optimizing code under src/black/ (I'm done optimizing src/blib2to3 for the time being). Once the Jupyter PR is merged, I'll have to deal with the introduced crashes. I guess the main thing I'm wondering is how early / late in the process should the changes be merged in. Expanded stability + performance testing is still something I need to do (deferred until I finish up the majority of optimizations) ... we could either do it before merge or after.

The general-I'm-glossing-over-many-smaller-details plan I had in mind goes roughly like this:

  • Finish up optimizations (edit: oh and I guess fix the the jupyter crashes)
  • Finish up the wheel building workflow
  • Check stability and collect official performance numbers on both Linux and Windows (I don't own a MacOS running machine)
  • Merge mypyc-support-pt2 into main <--- maybe we should move this item?
  • Perform expanded stability testing inviting members of the community to use the experimental compiled wheels
  • Once we're reasonably confident the compiled version won't crash, publish a black-mypyc package on PyPI (basically previous step but with an even bigger scope) (I stole this idea from mypy's mypyc rollout)
  • Integrate mypyc (ie. the wheel building workflow) into the main CD pipeline (and misc. like publishing docs)
  • Compiled wheels are shipped by default (ie. it's automatic opt-in)

cc @dense jungle did you have any knowledge / wisdom in this area from the mypyc rollout for mypy?

#

And yeah I'm expecting the above plan to take some time. While I'm not too worried that mypyc is going to break everything (from what I can tell mypy has been doing just fine with their mypyc compiled wheels), I'd like to avoid introducing too much breakage to people who haven't explicitly opted-in into this work.

#

Nothing in this plan is set in stone. This is definitely the biggest development project I've taken on for black and I don't have much experience managing and planning out these big multi-month projects. Feedback is highly welcomed :)

dense jungle
#

thanks for all your work on this! some thoughts:

  • I don't think we'll need to go through a separate black-mypyc package; that's a lot of complexity and it likely won't help that much (few people are going to use it if it's not the default). Don't put too much additional work on yourself
  • I'd like to start merging changes from the mypyc branch as soon as possible so you don't have to maintain too many patches
  • I can help perform benchmarks on MacOS
bright glacier
#
  • I can help perform benchmarks on MacOS
    Great thanks! Although honestly I'm more worried about the arm64 / universal2 wheels crashing on M1 since unfortunately they aren't testable during the wheel build on CI (GHA doesn't provide ARM MacOS runners).
#

I'd like to start merging changes from the mypyc branch as soon as possible so you don't have to maintain too many patches
Surprisingly there hasn't been many merge conflicts (although that may change once I start modifying the code under /src/black more) so this isn't as much as an issue.

#

I don't think we'll need to go through a separate black-mypyc package; that's a lot of complexity and it likely won't help that much (few people are going to use it if it's not the default). Don't put too much additional work on yourself
Fair enough πŸ˜„

bright glacier
#

This is the weird instability behaviour I brought up a few days ago. It's always the first value that's significantly slower than the others (well until another benchmark runs, but the point is that it's consistently inconsistent). This supposed to be a tuned system with a fixed CPU frequency and a isolated CPU core πŸ˜• . I've seen stable results but just haven't been able to get them for the parsing benchmarks ... (this issue seems less severe with the format-fast benchmarks for whatever reason ...)

Screenshot_from_2021-07-31_19-53-31.png
#

And no, more warmups don't help because which value in a process (run = process in pyperf land) ends up being the slow one changes for every benchmark ... (which has the fun side-effect of making some benchmark results quite stable because the slow one ended up being the warmup πŸ™ƒ)

#

Stripping out the outliers probably isn't that hard, but I wish I didn't have to do it in the first place (that's what pyperf + system tuning is supposed to handle).

rigid gorge
bright glacier
#

Oh so maybe it's not just my hardware playing poorly with this software. I don't know if that makes me feel better or worse ._.

#

Getting rid of the warmups seemed to make it significantly more stable. Not sure what that's all about but the weird consistent slowing down of a specific value seems to be gone *shrug*

plain atlas
rigid gorge
plain atlas
#

Well duh

rigid gorge
#

not sure how to explain more detailed than that

plain atlas
#

!pypi pytest-benchmark

late dewBOT
#
pytest-benchmark v3.4.1

A ``pytest`` fixture for benchmarking code. It will group the tests into rounds that are calibrated to the chosen timer.

rigid gorge
#

that works too

bright glacier
#

Anyway the upside of dealing with this mess is that I got my second round of numbers which look even better after my first wave of optimizations:

Faster (17):
- fmt-fast-dict-literal: 138 ms +- 5 ms -> 58.9 ms +- 3.6 ms: 2.34x faster
- fmt-fast-list-literal: 79.6 ms +- 2.7 ms -> 34.2 ms +- 2.1 ms: 2.33x faster
- fmt-fast-nested: 64.1 ms +- 2.2 ms -> 28.6 ms +- 3.0 ms: 2.24x faster
- fmt-fast-comments: 85.8 ms +- 2.7 ms -> 39.0 ms +- 2.7 ms: 2.20x faster
- fmt-fast-flit/sdist: 191 ms +- 7 ms -> 88.5 ms +- 8.2 ms: 2.16x faster
- fmt-fast-black/mode: 95.8 ms +- 3.2 ms -> 44.6 ms +- 2.6 ms: 2.15x faster
- fmt-fast-black/output: 88.5 ms +- 3.1 ms -> 41.2 ms +- 3.4 ms: 2.15x faster
- fmt-fast-black/strings: 158 ms +- 7 ms -> 74.5 ms +- 4.4 ms: 2.12x faster
- fmt-fast-black/linegen: 804 ms +- 30 ms -> 381 ms +- 27 ms: 2.11x faster
- fmt-fast-flit/install: 410 ms +- 22 ms -> 194 ms +- 12 ms: 2.11x faster
- fmt-fast-black/__init__: 843 ms +- 42 ms -> 400 ms +- 36 ms: 2.11x faster
- fmt-fast-black/brackets: 257 ms +- 8 ms -> 123 ms +- 14 ms: 2.09x faster
- fmt-fast-black/comments: 201 ms +- 7 ms -> 97.6 ms +- 7.9 ms: 2.06x faster
- fmt-fast-black/nodes: 648 ms +- 30 ms -> 321 ms +- 22 ms: 2.02x faster
- fmt-fast-black/lines: 584 ms +- 24 ms -> 294 ms +- 24 ms: 1.99x faster
- fmt-fast-flit_core/config: 552 ms +- 26 ms -> 288 ms +- 27 ms: 1.91x faster
- fmt-fast-strings-list: 25.1 ms +- 1.4 ms -> 13.8 ms +- 1.4 ms: 1.81x faster

Geometric mean: 2.11x faster
plain atlas
#

Yay!

#

Faster is better

#

Oh

#

I had a question now that I've realised where I am

bright glacier
#

What's your question πŸ˜„

plain atlas
#

The github action, does it print its logs in the way that github will notice them?

bright glacier
#

What do you mean? Like github statuses / checks?

#

In that case, no it does not, but could be a good feature to add!

plain atlas
#

Yeah

#

Right now I just run black in the github action instead of via pre commit

#

It uses the official pre-commit action

#

But not during CI, where it runs the "local" black with check and diff

#

So github actions reports that

bright glacier
#

Honestly I'm not following at all (in my defense, GitHub's way of naming stuff IMO suck)

plain atlas
#

I can find my logs of a failed run where black outputted a diff since a file failed when I get home

plain atlas
#

There's commit statuses, git actions workflows, etc

#

So yeah they're kinda bad tho

bright glacier
#

It started with when I used the GitHub REST API. The https://api.github.com/repos/psf/black/issues endpoint returns both issues and pull requests. In the API docs, they say that "pull requests are a superset of an issue" ... but sometimes you can get a response representing a Issue that isn't a subset of a pull request. Makes data modeling way harder than it should be.

plain atlas
#

Yeah uh

#

Issues and prs don't matter which endpoint it's the same 😠

bright glacier
#

I wished that they instead added a base concept that holds fields that both issues and pull requests share

#

Then I could make a Base class and add Issue(Base) and PullRequest(Base) subclasses and the data modeling would make sense.

plain atlas
#

random fact you probably don't know

#

semantic versioning and toml were invented by the same guy

#

and: tom is also the founder of github :)

bright glacier
#

I was going to search that up but I don't have a browser loaded and currently my system is quite slow so screw that (I'm effectively running a single-core system right now lol).

plain atlas
#

lol

bright glacier
#

But very much a TIL.

plain atlas
#

just curl that

bright glacier
#

Look, I have a dual-core APU and I isolated one of the cores (for benchmarking) so what else am I supposed to do. Fun fact, there's no hyper-threading either.

plain atlas
#

there u go

bright glacier
#

Thanks :^

plain atlas
#

anyways imma go mess with npm some more

#

cloudflare wrangler and npm play well together aka requires

plain atlas
#

ok

bright glacier
# 
--- src/black/parsing.py    2021-08-01 23:28:28.954903 +0000
+++ src/black/parsing.py    2021-08-01 23:28:38.210934 +0000
@@ -36,11 +36,13 @@
     else:
         ast3 = ast27 = ast
 
 if sys.version_info >= (3, 8):
     TYPE_IGNORE_CLASSES: Final[Tuple[Type, ...]] = (
-        ast3.TypeIgnore, ast27.TypeIgnore, ast.TypeIgnore
+        ast3.TypeIgnore,
+        ast27.TypeIgnore,
+        ast.TypeIgnore,
     )
 else:
     TYPE_IGNORE_CLASSES: Final[Tuple[Type, ...]] = (ast3.TypeIgnore, ast27.TypeIgnore)

I am confused at why black wants to explode this collection literal when it clearly doesn't violate the line-length limit (see next line) ...

#

Getting rid of the type annotation made it collapse the whole collection into one line ... whelp.

#

Oh, maybe I've been misremembering black's style. I could've sworn that the exploding logic for collection literals was the same as function definitions / calls.

#

19.10b0 and 20.8b1 have the same behaviour so yea looks like expected behaviour ^^

obtuse drum
#

where do should u chat

#

?

tribal thistle
proper tundra
#

.catify

silent apex
austere lava
#

jesus christ this is legal python

def f():
  return f" oh no {yield 1} nonononono"
#

WHY?!

bright glacier
#

:O

austere lava
#

sure enough, f() is a generator expression that yields 1

bright glacier
#

would be a fun bug to debug if you aren't vigilant :)

uncut patio
#

yield is an expression since the pep that adds generator coroutines

austere lava
#

it would've been so simple to prohibit crazy stuff like lambdas and yield in there

uncut patio
#

well, there would be a real usecase for f'the value of the coroutine is {yield from get_string()}'

dense jungle
#

I like this one ```def f():
for (yield 1)[1] in [1]:
pass

austere lava
#

oh yeah I recently learned about being able to put tuples and lists in comprehension targets

austere lava
austere lava
uncut patio
#

before async syntax in 3.5, the way you did async was using an @coroutine decorator and yield from instead of await

dense jungle
#

There's one instance of that in our codebase πŸ˜„

uncut patio
#

also, don't forget that anything that is a valid assignment target can be in a comprehension

def fib(n):
    return max(
        d[1]
        for d in [{}]
        for d[0], d[1] in [(0, 1)]
        for _ in range(n)
        for d[0], d[1] in [[d[1], d[0] + d[1]]]
    )
austere lava
#

right, right, but why would you not just

yield from x
"hello"
uncut patio
#

because yield and yield from are expressions

#

and have results

austere lava
#

more to my point I guess, when designing a language feature like f-strings, why not constrain it to disallow code that's going to be hard to understand πŸ™‚

dense jungle
#

Then you end up like with decorators where we've had multiple changes later to allow more syntax

bright glacier
#

eh, I don't find it confusing, just surprising at first glance

austere lava
#

but there's a big spectrum between "only names" and "any expression" πŸ™‚

austere lava
dense jungle
# austere lava is that a bad thing?

It means there's more unnecessary churn in the language definition. Like if you want to write @a[b] you need to think about what language versions you target

austere lava
#

that's an argument against any change to the language πŸ™‚

dense jungle
#

Sure, but the argument is stronger if the change could easily have been made earlier

uncut patio
#

trying to enforce clean code on a syntax level generally doesn't go well, you can always bypass it. People were doing

@getattr(None, '', lambda a: lambda b: a(b+1))
def fun(a):
    return a + 1
```long before decorators were made general
dense jungle
#

Like now you just need to remember 3.6 = f-strings, instead of needing to remember 3.6 = some f-strings, 3.7 = slightly different f-strings

austere lava
bright glacier
#

I sure hope the smaller-than-I-expected group of people using these are getting good use out of 'em :)

Screenshot_from_2021-08-03_15-22-18.png
#

not even 50 downloads combined lol

#

I'm surprised that Windows is neck-and-neck with Linux for download count (20 vs 21).

muted haven
# austere lava jesus christ this is legal python ``` def f(): return f" oh no {yield 1} nonon...

it is also pretty interesting how annotations interact with yields, even under __future__ annotations;

 $ python
Python 3.8.5+ (default, Mar 19 2021, 23:41:05) 
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from __future__ import annotations
>>> something: (yield)
>>> __annotations__
{'something': '(yield)'}
>>> def foo(bar: (yield)) -> (yield):
...     something: (yield another)
...     return 3
... 
>>> foo.__annotations__
{'bar': '(yield)', 'return': '(yield)'}
>>> foo(1)
<generator object foo at 0x7f48a04f8c10>
>>> next(foo(1))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
StopIteration: 3
dense jungle
austere lava
#

aha! so it doesn't matter if you're permissive or restrictive, there's always going to be churn πŸ˜›

austere lava
muted haven
#

but I believe only on 3.10

dense jungle
#

Oh yes there was an independent fix in 3.10

#

@austere lava fair point πŸ™‚

little parrot
dense jungle
#

you can also put walrus operators in for more fun

faint haven
#

Ah yes, a: type(a:=5), saves you having to update the type hint if you change the type of the variable πŸ™‚

lament crow
#

I like ```py

a: a.append(1) = []
a
[1]

errant barn
#

Or better yet:

>>> a: a.append(1) or type(a) = []
>>> a
[1]
>>> __annotations__
{'a': <class 'list'>}
uncut patio
#

type inference

vale robin
#

wdym? and that's not related to black

austere lava
dense jungle
austere lava
#

ye i was proud of that one

red crow
#

{"2.7", "3.6", "3.7", "3.8", "3.9", ("4.0" if gilectomy else "3.10")} i like this easter egg

bright glacier
uncut patio
#

as far as I can tell, the walrus is not a valid assignment target, but

for (z := 124)[0] in (x := -124):
    pass
```is valid syntax
bright glacier
#

yeah those cases were made by looking at the grammar

dense jungle
#

del (a := [1])[1] might work too?

plain atlas
zealous estuary
bright glacier
#

oh dear, pinging everyone or here sounds painful

#

good Python bot :)

flat krakenBOT
flat krakenBOT
stuck vapor
flat krakenBOT
bright glacier
#

Whelp, does anyone have any reason to block the merge? If not I'll press merge relatively soon.

#

!remind 2H don't forget to actually press the shiny green button on the jupyter PR

late dewBOT
#
ROGER THAT

Your reminder will arrive <t:1628280220:R>!

ID: 2717
dense jungle
#

Sorry I probably should have done that

flat krakenBOT
flat krakenBOT
bright glacier
#

Oh bloody heck, I prepped a Pipfile.lock related PR but the PR (which also touched Pipfile.lock) I merged above is now causing a merge conflict. Time to relock I suppose 😐

late dewBOT
#

@bright glacier

It has arrived!

Here's your reminder: don't forget to actually press the shiny green button on the jupyter PR.
[Jump back to when you created the reminder](#black-formatter message)

bright glacier
#

ugh, I'll deal with that soon, just need to deal with this merge conflict thing still (I got sidetracked with a help channel I was involved in :D)

#

I'm totally not messing up all of my git commands or anything πŸ˜…

#

finally! it only took a git stash, git merge main, git stash show -p > .diff, some manual modification of the diff because I can't do stashes today, and git apply .diff -3 phew

bright glacier
#

oh no, pipenv picked up my 3.9 installation, I hope this doesn't break anything

#

I should probably move to 3.9 soon, but I am really lazy so shrug

bright glacier
#

bloody hell what is pipenv doing:

+        "pytz": {
+            "editable": true,
+            "extras": [
+                "d"
+            ],
+            "path": "."
+        }
#

I have no idea why this happened ... did I make a mistake in Pipfile?

bright glacier
#

I see a few more TO-DO items but they can be handled later.

#

And nah it's OK, I didn't see that I said I would be merging it, must've read that and then forgot about it or something along those lines πŸ˜„

dense jungle
#

let's do it

flat krakenBOT
bright glacier
#

I am so confused, why did pipenv pull in pytz for even the normal dependencies, no where should black depend on pytz

#

I thought this would be a simple "make some changes to pipfile, relock, and you're good" but clearly not unfortunately

flat krakenBOT
#
ichard26
[psf/black] Issue opened: #2413 Follow\-up items for the Jupyter PR

PR #2357 was recently merged :tada: For the sake of getting it merged somewhat quickly and to not tire everyone, we left a few TO-DO items for later. This issue attempts to list 'em so we don't forget :)

  • Add documentation about the newly exported black-jupyter pre-commit hook
  • Look into whether we should add the Jupyter deps to Pipfile or just document the quirk (tox is unaffected)

I probably already forget a few tho, so feel free to edit / comment with more.

late dewBOT
#

@feral spade Please don't try to ping @everyone or @here. Your message has been removed. If you believe this was a mistake, please let staff know!

tribal thistle
plain atlas
#

never

#

well

#

I use gui for git diff and to unstage things

plain atlas
tribal thistle
#

Uhh

#

One of those things is not like the others

plain atlas
#

(its when I mess up the repo so much)

plain atlas
tribal thistle
#

No… GUIs…

#

I’m not saying they solve all your problems, but I’m not not saying that

#

Anyways probs ot

plain atlas
#

This is OT

lament crow
#

I don't trust most GUIs for Git

#

but Sublime Merge is nice 😏

plain atlas
# plain atlas This is OT

only 1/10 of the convo I see in here is about black, and the other 8/10 are with black users and devs

solar knot
#

is there a vscode plugin for black?

bright glacier
#

IIRC vscode has basic support for black via the python extension

#

it's one of your options in choosing a formatting provider for python

#

And because I thought the toml story couldn't get anymore confusing / annoying, now the type ignore that's currently present to the bare CR thing (so let's use bytes) is causing mypyc issues, gah!

plain atlas
#

wait where's the rest of the story

#

I'm curious because all of my projects now have toml and tomli as dev dependencies for coverage and black respectively

bright glacier
#

so apparently bare CR isn't actually a valid newline sequence if you want to follow the TOML spec to the letter

plain atlas
#

AH

#

FTR, this is what VSC lets me pick

#

no just CR

bright glacier
#

so everyone doing with open("file.toml", "r", encoding="utf-8") as f: data = tomli.load(f) is technically against the spec

#

now IMO it's a bit "are you kidding me"

plain atlas
#

i remember seeing a pull or issue on the toml github repo to change the spec to what is actually used lol

bright glacier
#

anyway, tomli in the interest of following the spec has deprecated strings and textIO

#

and apparently the type annotations have already been changed

plain atlas
#

wait what

#

oh

bright glacier
#

so now our type checker is complaining on technically working code

plain atlas
#

fun

bright glacier
#

I really wished tomli changed the type annotation to something like Union[bytes, str]

#

because that is the actual support surface

#

I get you want everyone to switch, but given that all of this might end up reverted, it is very annoying

plain atlas
#

yeah

#

well

#

I guess I have some free time

#

@bright glacier why use tomli over toml?

bright glacier
#

toml is unmaintained

plain atlas
#

!pypi toml

late dewBOT
plain atlas
#

!pypi tomli

late dewBOT
bright glacier
#

toml has no support for TOML v1.0.0rc (not sure it's stable yet)

plain atlas
#

oh uh

#

lmfao

#

tfw toml links to

#

as the current spec

bright glacier
#

this entire story is honestly really frustrating

#

it feels even more unstable than the packaging world (as much as people really like to comment that it's moving too quickly)

plain atlas
#

lol

#

hm

#

a third challenger

#

!pypi tomlkit

late dewBOT
plain atlas
#

which is what one of my orgs subprojects uses right now

bright glacier
#

I think that's other still maintained toml library

plain atlas
#

yeah

#

extremely maintained

#

TOML Kit is a 1.0.0rc1-compliant TOML library.

bright glacier
#

tomlkit is the slowest out of the bunch

plain atlas
#

oh?

bright glacier
#

makes sense given that has style preserving behaviour

plain atlas
#

actually "toml" is the slowest kthx

#

:)

bright glacier
#

my bad

plain atlas
#

lol

#

wait

#

i just read something and now...

#

why would python adopt this

#

Whitespace means tab (0x09) or space (0x20).

#

something that supports both is the cause of all evil

plain atlas
bright glacier
#

honestly I don't mind tabs that much

plain atlas
#

tomlkit is still out of date

bright glacier
#

like I don't care which one you want to use, just please be consistent in which one

plain atlas
#

tomlkit

firefox_ugZoD7Y5cg.png
plain atlas
#

like that fucked me up multiple times

bright glacier
# 
❯ python setup.py --use-mypyc bdist_wheel
Parsed and typechecked in 8.267s
Compiled to C in 0.000s
src/black/handle_ipynb_magics.py:228:5: error: Statement is unreachable
src/black/handle_ipynb_magics.py:351:31: error: Incompatible types in assignment (expression has type "CellMagic", variable has type "None")

this is annoying

plain atlas
bright glacier
#

the previous was cuter IMO

plain atlas
#

Β―_(ツ)_/Β―

#

its was too cute for pydis imo

bright glacier
#

WHAT DO YOU MEAN TOO CUTE

plain atlas
#

Β―_(ツ)_/Β―

bright glacier
# 
+[mypy-black.files]
+# Unfortunately tomli has deprecated strings and changed the API type
+# annotations to bytes all while strings still work. We still use strings
+# since it's unclear whether this will last (depends on how much the
+# TOML people like bare CR as a newline sequence I suppose).
+#
+# See also: https://github.com/psf/black/pull/2408
+#           https://github.com/pypa/pip/pull/10238 (because black is
+#             following whatever they do)
+#           https://github.com/toml-lang/toml/issues/837
+warn_unused_ignores=False
diff --git a/src/black/han

seems about right lol

plain atlas
#

imma go work on configurave lol

#

its a project that will import from toml files or export to toml and combine it with enviroment variables and custom sources

#

because toml is superior to yaml

#

but json is the ultimate best /s

#

ask me about configurave

bright glacier
#

I'm too wrapped up in making mypyc not generate broken code right now

plain atlas
#

lol

#

set a reminder

bright glacier
#

no.

plain atlas
#

what even is mypyc

bright glacier
#

!remind 5D maybe, just maybe ask about configurave

late dewBOT
#
Alright.

Your reminder will arrive <t:1628732794:R>!

ID: 2719
plain atlas
#

:)

bright glacier
plain atlas
#

black is compiled into C?

bright glacier
#

yep! C extensions to be exact

plain atlas
#

ah

#

wait i have a quick question, what would you use for a tui?

#

black uses click, but if you had to choose like idk

bright glacier
#

you mean command line interface?

plain atlas
#

yeah

bright glacier
#

TUI usually means a GUI but in a terminal

#

honestly I haven't used argparse much so I would try that

plain atlas
#

lol yeah, its because of the code jam

bright glacier
#

but I don't like any of them

plain atlas
#

is argparse in the stdlib?

bright glacier
#

yes

#

click + cloup is the most tolerable so far

#

for me to be clear

plain atlas
#

well that settles it ig, lol. I don't want to add any additional deps to this

#

i know of (translated: I know they exist) click, cleo, typer

bright glacier
#

typer is rather unmaintained these days

#

it doesn't support click 8+

plain atlas
#

ah

#

!pypi typer

late dewBOT
#
typer v0.3.2

Typer, build great CLIs. Easy to code. Based on Python type hints.

plain atlas
bright glacier
#

typer is based off click

plain atlas
#

oh

late dewBOT
#

pyproject.toml lines 29 to 31

requires = [
    "click >= 7.1.1, <7.2.0"
]```
plain atlas
#

i c

#

huh

#

flit

bright glacier
#

flit is a nice packaging tool

plain atlas
#

arguably I like poetry's dependency lists more

bright glacier
#

it still doesn't solve the "I have 5 different overlapping sets of dev dependencies" problem but it's still way nicer to use

plain atlas
#

I have 5 different overlapping sets of dev dependencies
dev dependencies that aren't compatiaible?

#

or like tests/docs/build dependencies?

bright glacier
#

I mean like: lint, tests, docs, docs-extra, dev (which should contain everything before).

plain atlas
#

ah

bright glacier
#

basically I wish you could combine extras

plain atlas
#

I get to spoil the surprise then :)

#

Poetry is adding dependency groups in 1.2

plain atlas
bright glacier
#

flit's notion of dev vs production dependenies would work

#

if I didn't have two groups each for both lint + docs

plain atlas
#

wdym?

#

does black use flit

#

!pypi black

late dewBOT
bright glacier
#

No, but I use it for blackbench.

# 
❯ lexa requirements/
.rw-rw-r-- 106 ichard26 ichard26 23 Jul 18:55 docs-base.txt
.rw-rw-r--  28 ichard26 ichard26 23 Jul 18:55 docs-live.txt
.rw-rw-r--  18 ichard26 ichard26 23 Jul 18:55 lint-base.txt
.rw-rw-r--  50 ichard26 ichard26 23 Jul 18:55 lint-extra.txt
.rw-rw-r--  14 ichard26 ichard26 23 Jul 18:55 tests-base.txt
.rw-rw-r--  35 ichard26 ichard26 23 Jul 18:55 tests-cov.txt

is my current solution

plain atlas
bright glacier
#

it's still in alpha πŸ˜‰

plain atlas
#

add blackbench to pypi

#

as alpha

#

:)

bright glacier
#

I will, but I want to deal with a few more things first

#

!gh ichard26/blackbench

#

wait what

plain atlas
#

why is that not a command

#

oh

#

.gh ichard26/blackbench

#

because it'll let you

bright glacier
#

direct link works too πŸ™‚

plain atlas
#

bad ichard26

firefox_7OPYFzUl6G.png
#

smh I can't look at this repo

#

aaaaaa

#

my CI and dependency/tools side is showing

bright glacier
#

to be fair, it's like my first proper open source project

plain atlas
#

.coveragerc can be in pyproject.toml :)

bright glacier
#

and I do use nox so it's the not the worse TM

plain atlas
#

and codecov.yml can be a hidden file named .codecov.yml

bright glacier
#

I don't use the hidden feature of dotted names

#

but sure, I guess I can roll that into my modernization branch I have locally

plain atlas
#

ah, you don't like it, that's fine lol

bright glacier
#

it's not that I don't like it, it's just that I don't care

plain atlas
#

I just prefer as many third party config files as I can to start with .

#

in my case, because I use isort too, I configure both flake8 and isort in tox.ini

#

but do agree if not having isort, .flake8 is better named lol

#

like you have it

#

oooooh

bright glacier
#

?

plain atlas
#

@bright glacier here's some info for you