Python 3.10 Fizzbuzz

[Mats Wichmann]

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).

Many teams find the removal of this potential disagreement valuable - 
there's plenty of more important stuff to spend time on. If as an 
individual user, not trying to conform to style choices of a project, it 
doesn't appeal, there's no need to fuss with it.

One can certainly pick a different code style, and make sure it's 
captured in the rules for one of the several more flexible formatting 
tools (for example, I *used* to use yapf pretty regularly, and had that 
tuned as I wanted)