Django: Reformatted code with Black

Post by dnate » Tue, Feb 08, 2022, 11:38 PM UTC

jessaustin wrote: post #156

3pt14159 wrote: post #117

Earlier quoted context omitted.

Well, sorta. It's really, really mentally annoying switching between projects where standards are different. For example 80 char limit to 120 char limit takes me at least a month to fully get used to. I agree black is better than the alternative, I agree it has downsides, I'm happy some of the parameters are tunable, but I'm also glad most of them are not. I just want to write software with tools I'm used to.

Who is using 120 chars?!?!? I can certainly understand the adjustment difficulties...

Post by bwhmather » Tue, Feb 08, 2022, 11:43 PM UTC

bwhmather wrote: post #122

drcongo wrote: post #106

Earlier quoted context omitted.

This is relevant to my interests. We have an internal code style guide at my company that includes guidelines for order of class statements, roughly matching yours. I have one pet peeve that made me write the style guide in the first place - Django's `class Meta` which we always have at the top of the class because it contains vital information you need to know as a programmer, like whether this class is abstract or…

I've had the same problem with pydantic. Currently, properties are special cased and moved to the top. Everything else, including classes, is grouped with methods. Meta classes will end up somewhere in the middle, which is probably the worst possible case. SSort is currently used for several hundred kilobytes of python so I'm wary, but if I'm going to make a breaking change before 1.0 then I think this is likely to b…

Post by zmmmmm » Wed, Feb 09, 2022, 12:02 AM UTC

throwaway894345 wrote: post #59

tomp wrote: post #27

worst things about Black: - doesn't respect vertical space - sure, making the code fit on screen might be valuable (though the default width should be at least 120 characters, I mean we're in 2022 after all), but Black does it by blowing up the vertical space used by the code - spurious changes in commits - if you happen to indent a block, Black will cause lines to break - Black fails at its most basic premise - "avo…

> oesn't respect vertical space - sure, making the code fit on screen might be valuable (though the default width should be at least 120 characters, I mean we're in 2022 after all), but Black does it by blowing up the vertical space used by the code This is fine with me--I think it makes sense to optimize for readability, and I can read a long vertical list of arguments a lot more readily than a long comma-delineated…

Post by OJFord » Wed, Feb 09, 2022, 12:33 AM UTC

mrtranscendence wrote: post #182

OJFord wrote: post #86

Earlier quoted context omitted.

My preference is actually for what GP doesn't like; the reason I don't like your suggestion is that: from typing import ( overload, ) is silly, but I don't want: -from typing import overload +from typing import ( + overload, + List, +) when all I actually did (semantically) was: + List,

It feels to me like importing names from a module gets you a set of names from that module, so I'm already thinking about it as a collection. It doesn't bother me at all that it's turned into a tuple and spread over multiple lines.

    from typing:
        import overload
        import List

Post by Bedon292 » Wed, Feb 09, 2022, 12:52 AM UTC

BiteCode_dev wrote: post #97

bwhmather wrote: post #84

Shameless 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

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.