>uncompromising
But does it have an #ignoreformatter directive?
Black – Uncompromising Python code formatter
141–150 of 251 posts
Re: Black – Uncompromising Python code formatter
#142I sincerely hope that adding this to your project is referred to as "taking the Black." Too good an opportunity to miss.
Re: Black – Uncompromising Python code formatter
#143I often dislike autoformatter output too, but then I remember that while no-one likes what the autoformatter does to their code, everyone likes what the autoformatter does to their coworkers' code, and then I chill out about it. Having a standard is more important than the standard being excellent.
Why not let every user apply their own formatter? I bet that with a little work in the toolchain (git, editors, less), you can make this work.
Re: Black – Uncompromising Python code formatter
#144The ford logo is a nice touch.
For anyone who doesn't get it, the name and logo comes from the famous story where Henry Ford, maker of the Model T -- one of the first affordable automobiles, because it was made on an assembly line -- said "Any customer can have a car painted any color that he wants so long as it is black." This quote and assembly-line idea translate into the branding of this project. (The project logo is visually similar to the modern Ford company logo, but with the word Black instead of Ford.)
Re: Black – Uncompromising Python code formatter
#145Black is an awesome tool. You might not like one or two of their decisions, but it completely eliminates discussions related to taste on a given team and the fact it is not configurable is its biggest value proposition.
Re: Black – Uncompromising Python code formatter
#146Earlier quoted context omitted.
No, we can't. My (and, by the sound of it, CrLf's) favorite format relies on information that your pre-commit hook has artificially removed from the code. Eg: munge(gidget, thing1,thing2,thing3); cmplt(dtypeA,valueA, dtypeB,valueB); (Most cases are more subtle (and thus less amenable to "oh, you just need to build a complete static type checker into the formatter") than this, but I wanted an obvious example.)
It seems like the signature of the functions should be different, especially the second example. I would have written the cmplt function to take tuple pairs: cmplt( (type_a, value_a), (type_b, value_b), ) That's much more clear about the relationship between each pair of values either way, and would get formatted nicely by Black.
Sorry, should have clarified: my example was written in C[0][1]; cmplt is something like (Dtyp* ,Dval* ,Dtyp* ,Dval* ), which is what I was alluding to with "just need a type checker". Also, in the code I anonymised that from, cmplt and munge are imported (well, #included) functions from a different library.
0: which doesn't have tuples anyway; you could use structs, but it doesn't really work well in context/practice.
1: I don't use python frecently enough to have ready examples of autoformatter stupidity on hand for it.
Re: Black – Uncompromising Python code formatter
#147Auto formatters are great but the problem with Black is that Python is fundamentally incompatible with them, at least if you're only willing to insert whitespace. For example a line of code like this:
x = y[1]['a'] + z[2]['b']
x = y[1][
'a'] + z[2]['b']
x = (
y[1]['a']
+ z[2]['b']
)
Re: Black – Uncompromising Python code formatter
#148Earlier quoted context omitted.
> Having a standard is more important... Let me take a shot at why it's important. We spend years peering at code hunting for tiny, miniscule mistakes. Thus we're training ourselves, quite rigorously, to spot minor deviations. We're also irrational in the moment: our aesthetic sense is bothered by certain patterns, and our social sense wants to assign blame for this "wrongness" to individuals. An auto-formatter remov…
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
Re: Black – Uncompromising Python code formatter
#149Auto formatters are great but the problem with Black is that Python is fundamentally incompatible with them, at least if you're only willing to insert whitespace. For example a line of code like this: x = y[1]['a'] + z[2]['b'] can be broken like this in Black (if it's over the line length limit): x = y[1][ 'a'] + z[2]['b'] But it needs brackets inserted so that it can be formatted something like this: x = ( y[1]['a']…
Black does add brackets in some situations.
Re: Black – Uncompromising Python code formatter
#150Against 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…
[deleted]