241–250 of 251 posts
Why on earth would it convert this: printable_chars = { 33, 34, 35 [...and another few hundred ] to printable_chars = { 33, 34, 35 [...and another few hundred lines ]
Those look the same to me.
Why on earth would it convert this: printable_chars = { 33, 34, 35 [...and another few hundred ] to printable_chars = { 33, 34, 35 [...and another few hundred lines ]
printable_chars = { 33, 34, 35 [...and another few hundred ]
printable_chars = {
33,
34,
35
[...and another few hundred lines ]
}Played around with it in the sandbox and immediately disliked its insistence on putting every item in a sufficiently-long array on its own line. For example, something like: foo = [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30 ] Black formats it to something more like: foo = [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22…
Because it’s optimised for producing the smallest diff once it’s already been formatted and a change is made. If you add a single item to your preferred style, the entire thing has to be reflowed.
A good diff will tell you:
foo = [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18,
19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30 ]
>> foo = [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 10, 11, 12, 13, 14, 15, 16, 17, 18,
19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30 ]
Against my better judgment I'll bite. I super dislike black's formatting, and I think it's really rare to actually see it in codebases. It wraps weirdly (sometimes not at all). I'd prefer to use yapf, but last I checked it still crashes on "f-strings". Here's a small example: basket.add({ apple.stem for satchel in satchels for apple in satchel }) Black formats this as: basket.add( { apple.stem for satchel in satchels…
> there's a wealth of prior art to look at Precisely. I wonder why ML has not been applied here.
Earlier quoted context omitted.
Unrelated: thank you for using “idempotent” correctly. Too many people use it to mean referential transparency or having a functionality property
wooow, so can we think of Black as outputing a projection of your source code in some space ?
Earlier quoted context omitted.
wooow, so can we think of Black as outputing a projection of your source code in some space ?
wut? idempotent is any operator T such that T^2=e the identity. for example ring elements can be idempotent https://en.m.wikipedia.org/wiki/Idempotent_(ring_theory) . it's not just characteristic of linear operators.
Earlier quoted context omitted.
wut? idempotent is any operator T such that T^2=e the identity. for example ring elements can be idempotent https://en.m.wikipedia.org/wiki/Idempotent_(ring_theory) . it's not just characteristic of linear operators.
Idempotence means T^2=T. Are you thinking of involution? https://en.wikipedia.org/wiki/Involution_(mathematics)
Earlier quoted context omitted.
Agree 100%, except for a minor quibble at the end. I've tried a few small projects with pipenv and black recently, and though I love black, I'm still struggling to accept pipenv as good. It's so slow so often, and I can't understand why.
I've previously profiled pipenv and found it to be slowed down massively due to launching pip for each package it was working on. Unfortunately the maintainers think the progress bar is more important than performance: https://github.com/pypa/pipenv/issues/2207
It would be nice if pip could act more as a base tool and pass information back to a wrapper.
Having worked in Python for many years, I can tell you that nobody actually writes code that looks like Blacks formatting. It's a major step backward for the Python community.
Having worked in Python and other languages for many years, I can tell you that 1) this doesn't matter and 2) many of the ways people write Python are much uglier than the conventional formatting in other languages. Most notably: this_is_my_very_long_function_name_and_here_come_the_args(self, foo, bar, baz)
Played around with it in the sandbox and immediately disliked its insistence on putting every item in a sufficiently-long array on its own line. For example, something like: foo = [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30 ] Black formats it to something more like: foo = [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22…
Because it’s optimised for producing the smallest diff once it’s already been formatted and a change is made. If you add a single item to your preferred style, the entire thing has to be reflowed.
Even in a case where I need to add an item in the middle, the diff will - again - only start where I actually added an item, and any human can readily see that the rest of the downstream diffs were from the reflow.
Of course, it'd be even better if diff tools were more aware of the format/language of the code being diff'd, at which point it'd be able to say "new element added to foo" instead of reporting on a bunch of reflowed lines.