[Tutor] creating and writing to a text file

[Mats Wichmann]

Okay, I promise last from me on this subject.

Black has become very popular.  It solves, in a brute-force way, a 
particular problem: in a team, there are going to be people with 
slightly different ideas of style.  The organization can grunt their way 
through producing a style document, and then someone agrees 95% with it, 
but wants to write a dict with a space before the colon: {'foo' : 12}, 
or drop the space before a colon in a type annotation ( def foo(arg:int) 
-> int ) both of which are completely harmless, or not even consciously 
do something like that but have it unconciously entered in while 
typing).  If those draw review comments on a code submission, that's 
wasted time to deal with - to make and to respond to. Instead, trust 
that the tool has fixed it to "the style" and just don't comment on 
those. So Black wants to have you stop looking at style and focus on 
content in code review scenarios.

But Im' not arguing *for* it, If the above is not a winning argument in 
a give scenario, fine. Don't use Black.  There's no moral imperative to 
do so.

On 3/30/21 3:21 PM, Cameron Simpson wrote:
> On 30Mar2021 09:23, Alan Gauld <learn2program at gmail.com> wrote:
>> On 30/03/2021 07:18, Cameron Simpson wrote:
>>> If you're talking about pyflakes, it's a linter:
>>>      https://pypi.org/project/pyflakes/
>>>
>>> It actually promises to not complain about style :-)
>>>
>> I'm a big fan of linters but I hate formatters.
> 
> I have mixed feelings, but yapf can be tuned to very close to my
> preferred style anyway.

And that's absolutely fine, it's your code, use what makes you happy. I 
really liked yapf at first.  Then I started running into format 
arguments on a particular project. The case for format tools that can be 
invoked automatically is to keep people from disagreeing about stuff 
that really shouldn't matter. Not to tell you your style is wrong... 
though it can sort of have that effect, sometimes. Sigh.

>> There's very little evidence that strict code formatting makes much
>> difference
>> to comprehension
> 
> Aye, but I'm prone to trivial typos (spaces, etc) and poorly formatted
> code annoying me, doubly so when it is my own poorly formatted code. It
> _is_ very pleasing to me to have a computer apply that rigour for me.
> 
>> and in practice I find that different styles apply in
>> different
>> parts of the code specifically as a way of conveying meaning(*). Formatters
>> tend to remove those variations.
>>
>> I avoid them like the plague!
>>
>> (*) an example would be building a menu system from a data structure,
>> it makes sense to lay the data out to look like the menus. but in other
>> places you want it to look like a flat data store. Most formatters
>> insist on
>> lining everything up according to whatever scheme their author prefers
>> (or if you are lucky a config setting)
> 
> Yes, this is true. Even yapf doesn't indent dict literals (for eg) as I
> want. It _does_ at least have a lexical cue in that a trailing comma
> lines all the values up vertically, and no trailing commas makes it fill
> the lines.

If you do feel like a chunk needs particular formatting for readability, 
alignment to external views, etc. you can usually tell formatters to 
keep their hands off, just like you can tell checkers to ignore certain 
things.  Even the "unconfigurable" Black can do this:

"Your main option of configuring Black is that it doesn't reformat 
blocks that start with # fmt: off and end with # fmt: on, or lines that 
ends with # fmt: skip."