Python 3.10 Fizzbuzz

[Oscar Benjamin]

On Tue, 28 Feb 2023 at 20:55, Mats Wichmann <mats at wichmann.us> wrote:
>
> On 2/27/23 16:42, Oscar Benjamin wrote:
> > On Mon, 27 Feb 2023 at 21:06, Ethan Furman <ethan at stoneleaf.us> wrote:
> >>
> >> On 2/27/23 12:20, rbowman wrote:
> >>
> >>   > "By using Black, you agree to cede control over minutiae of hand-
> >>   > formatting. In return, Black gives you speed, determinism, and freedom
> >>   > from pycodestyle nagging about formatting. You will save time and mental
> >>   > energy for more important matters."
> >>   >
> >>   > Somehow I don't think we would get along very well. I'm a little on the
> >>   > opinionated side myself.
> >>
> >> I personally cannot stand Black.  It feels like every major choice it makes (and some minor ones) are exactly the
> >> opposite of the choice I make.
> >
> > I agree partially. There are two types of decisions black makes:
> >
> > 1. Leave the code alone because it seems okay or make small modifications.
> > 2. Reformat the code because it violates some generic rule (like line
> > too long or something).
> >
> > I've recently tried Black and mostly for my code it seems to go with 1
> > (code looks okay). There might be some minor changes like double vs
> > single quotes but I really don't care about those. In that sense me
> > and Black seem to agree.
> >
> > However I have also reviewed code where it is clear that the author
> > has used black and their code came under case 2. In that case Black
> > seems to produce awful things. What I can't understand is someone
> > accepting the awful rewrite rather than just fixing the code. Treating
> > Black almost like a linter makes sense to me but accepting the
> > rewrites that it offers for bad code does not.
>
> The amount of disagreement you see here and elsewhere are exactly why
> Black  is like it is - virtually without options.  It doesn't aim to
> solve the challenge of producing The Most Beautiful Code Layout, for
> *you*, or even for any moderately sized group of programmers.  Instead
> it's to remove the bickering:
> 1. we choose to use black for a project.
> 2. black runs automatically
> 3. there is now no need to spend cycles thinking about code-style
> aspects in reviews, or when we're making changes, because black makes
> sure the code aligns with the chosen style (1).

The problem is that although Black runs automatically it doesn't solve
the code problems automatically. Instead it takes something
questionable and produces something worse. If Black just rejected the
author's code and told them to write something better then they
probably would produce something better than what Black produces.

The limitation of Black is that it only reformats but usually at the
point when it does that the option of reformatting is not really the
thing that needs doing. Instead the right option is something like
introducing a new variable to split one statement into two but Black
just goes ahead and reformats without considering that option.

I'm fine with not arguing about what kinds of quotes to use but that
doesn't mean that I'll accept any output from Black without arguing
about the code being improved.

--
Oscar