Earlier quoted context omitted.
Yes, it's opinionated, but who's opinion got carved into stone?
Does it matter?
Well, someone convinced the Python community that their coding standard should be the one coding standard.
Django: Reformatted code with Black
241–250 of 256 posts
Re: Django: Reformatted code with Black
#242Earlier quoted context omitted.
I did a blind survey of YAPF vs Black at my work. The results came back as 70% in favour of Black. Black gives generally nicer output, and also more predictable output because its folding algorithm is simpler. YAPF uses a global optimisation which makes it make very strange decisions sometimes. Black does too, but much less often. There are also non-style problems with YAPF. It occasionally fails to produce stable ou…
How did you perform the blind survey? Format some code with Black and YAPF and ask people which they liked better?
Yeah exactly. I had 20 samples from our codebase that showed some representative differences and you had to click on which one you liked more. The order (Black/YAPF or YAPF/Black) was randomised.
I also had to turn off Black's quote normalisation otherwise it is really obvious which is which. Quote normalisation is another point in Black's favour.
I could put the survey up somewhere if anyone is interested.
Re: Django: Reformatted code with Black
#243Shameless plug: For people who like black, I've been working on ssort[0], a python source code sorter that will organize python statements into topological order based on their dependencies. It aims to resolve a similar source of bikeshedding and back and forth commits. 0: https://github.com/bwhmather/ssort
this is great. Imagine i declare global variable which is used in function which is defined AFTER this global variable is declared (filled by value) and then function is executed later. Why does ssort put my declaration/filling of global variable before that function declaration?
def myfunc(): global globalvar str(globalvar)
globalvar='abc'
myfunc()
will be transfered to
globalvar='abc'
def myfunc(): global globalvar str(globalvar)
myfunc()
I understand why is it done but i dont want to have function definition block filled with this declaration of variables (which i do later) since it has no impact to my code and it makes is just a bit "cleaner". Dont tell me to not use global variables :D
Re: Django: Reformatted code with Black
#244Earlier quoted context omitted.
> - Black fails at its most basic premise - "avoiding manual code formatting" - because a trailing comma causes a list/function call to be split over lines regardless of width Yeah, this one drives me nuts too.
It's one of my favorite things about black, and I've started to use that formatting of function calls with long arguments for other languages too. But I also despise long lines with a passion, I hate having to go to the right, and would much much rather scroll up and down with a consistent width, so that I can put multiple views next to each other.
I don’t mind the formatting, I mind that the formatting is done depending on wether the list ends with a comma or not.
[
Item1,
Item2
]
[
Item1,
Item2,
]
Re: Django: Reformatted code with Black
#245Earlier quoted context omitted.
> - Black fails at its most basic premise - "avoiding manual code formatting" - because a trailing comma causes a list/function call to be split over lines regardless of width Yeah, this one drives me nuts too.
If I'm understanding your problem correctly, it seems that you can avoid it by using the --skip-magic-trailing-comma option [0]. [0] https://black.readthedocs.io/en/stable/the_black_code_style/...
Yes, but wasn’t the whole point not having to run the linter with options.
The trailing comma thing seems inconsistent with handing over the formatting to black. Now I’m in charge of deciding if a list should be cleaned up into one line or not.
Re: Django: Reformatted code with Black
#246Earlier quoted context omitted.
Maybe it's because I only have one eye and the resulting slightly reduced width of field, but wide lines drive me crazy. I need to see the whole line without scanning. This was one of python's original appeals to me... https://pep8.org/#maximum-line-length
I can see how that would make it hard for you. I hope your team is accommodating.
I'm like her in that I have eye issues and thus can't use screens that are too large (16" absolute maximum) and even there it needs to be with large font. I wish everyone had stayed with 80 chars so I could have two vertical emacs buffers, but I've sorta gotten used to these ugly wrap around lines.
I wish people just used more locals though. I don't see what the problem is and it makes Sentry errors easier to debug.
Re: Django: Reformatted code with Black
#247Earlier quoted context omitted.
Very interesting, especially the method order part. I dislike the order you chose, and yet, I would be tempted to use it on my projects anyway, because being congruent is so important to me.
A standard no one likes is often better than no standard at all.
It’s an unfortunate compromise with code formatters. As someone who takes code formatting really serious and puts a lot of manual thought into code formatting, code formatters almost always make my code worse, in my opinion, or at best unchanged outside of small errors like double spaces, etc. But it creates a standard that it loves everyone’s code towards, which is good., and also obviously alleviates the chore of manually formatting.
I just wish sometimes they were more configurable. For example, the Elixir formatter is quite opinionated on things but is generally not configurable.
Re: Django: Reformatted code with Black
#248Earlier quoted context omitted.
I disagree on that though. By sticking to vanilla Black (no pun intended) you ensure that people joining your time will probably already be familiar with the style, you prevent strongly opinionated employees from pushing for changes in the linter config. Black is opinionated, so it skips the debate entirely. We just use Black, not black with 120 characters lines, just Black. To each their own I guess, but to me it ju…
Yes, it's opinionated, but who's opinion got carved into stone?
That does not really matter as long as the default are somewhat sensible. As far as I can tell Black's are.
gofmt is also opiniated. Someone somewhere picked the defaults and maybe I disagree with those defaults, but in the grand scheme of things, all go code is more approachable because it all looks the same. That to me, is worth a lot more than having my favorite format be the one on top.
EDIT: If you want to discuss the actual merits of Black, you can read their style page that actually explains every choice they made: https://black.readthedocs.io/en/stable/the_black_code_style/...
Re: Django: Reformatted code with Black
#249Earlier quoted context omitted.
A standard no one likes is often better than no standard at all.
It’s an unfortunate compromise with code formatters. As someone who takes code formatting really serious and puts a lot of manual thought into code formatting, code formatters almost always make my code worse, in my opinion, or at best unchanged outside of small errors like double spaces, etc. But it creates a standard that it loves everyone’s code towards, which is good., and also obviously alleviates the chore of m…
I often wish they were _less_ configurable. Even Black's handful of config options are too many... Each one is a chance to pick a whole new color for the bikeshed.
Re: Django: Reformatted code with Black
#250Earlier quoted context omitted.
For me µsort is a non-starter since it doesn't ignore the import/from part when sorting lexicographically. So when an import changes from `import foo` to `from foo import bar` (and vice versa), the import is moved. Sorting should start at the package name, nothing else.
I suspect you are fighting the tide of common practice in the Python community. In your example, switching from `import foo` to `from foo import bar` is changing the entire nature of the import. Sorting module- and from-imports separately also makes it much easier for many people to visually scan a block of imports. And similar to black, having a tool be consistent and predictable across projects and modules is more…
> I suspect you are fighting the tide of common practice in the Python community.
I hope not!
> Sorting module- and from-imports separately also makes it much easier for many people to visually scan a block of imports.
For me it's the opposite. My brain skips over the irrelevant parts (i.e. import/from). Not moving the import also produces better git diffs