git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Black


On 21Oct2019 07:18, lizhollinshead5 at gmail.com <lizhollinshead5 at gmail.com> wrote:
>What do people think about black?

Personally, I prefer yapf. Details below.

>I'm asking because one of my personal preferences is to use spaces for clarity:
>
>1.  right = mystr[ start : ]
>
>         black version     right=mystr[start:]
>
>2.  mtime = time.asctime( time.localtime( info.st_mtime ) )
>
>         black version     mtime = time.asctime(time.localtime(info.st_mtime))
>
>Is there a reason why PEP8 doesn't like these spaces?

Probably compactness and the personal opinions of the python devs at the 
time.

Also, PEP8 is for the stdlib. It is certainly a reasonable style for 
other code, but you're under no obligation to use it, either rigidly or 
at all).

I was asked this question back in June (I prefer yapf to black, more 
tunable), and I'll repost my reply here:

On 29Jun2019 10:19, Malcolm Greene <python at bdurham.com> wrote:
> > I've also taken to having my files auto-formatted with yapf on save 
> > ...
>
> @Cameron: Have you considered black at all and if so, what are your 
> thoughts?

I did consider black. Its core selling point was its total 
inflexibility.  Use this and stop _caring_ about the formatting: it will 
be PEP8 compliant and readable. It is like "go fmt" in that regard 
(Which I use with Go, when I use Go - you can see that in the "format" 
script I posted).

The target here is: all code uses the same style, the chosen style is 
good (readable, reasonable, acceptable to most people), let's just use 
it and spent our time worrying about coding instead of style.

However, I want flexibility.

Like the OP, I use 2 spece indentation and have my own foibles. Here is 
the .style.yapf file I use in my personal code:

    [style]
    based_on_style = pep8
    blank_line_before_module_docstring = True
    blank_line_before_nested_class_or_def = True
    blank_lines_around_top_level_definition = 1
    dedent_closing_brackets = True
    #indent_dictionary_value = True
    indent_width = 2
    split_before_expression_after_opening_paren = True
    split_before_first_argument = True
    split_complex_comprehension = True
    space_between_ending_comma_and_closing_bracket = False
    split_before_dot = true
    use_tabs = False

This comes remarkably close to the style I was hand applying before 
biting the bullet and putting in the work required to get my editor to 
autoformat on save.

[ Aside: another nice thing about autoformatting, over the "nice!" 
feeling one gets seeing the code shuffle around in front of one's face, 
is that if there's a syntax error the code _doesn't_ shuffle around and 
one can go "whoops" and eyeball the code more closely. ]

Cheers,
Cameron Simpson <cs at cskk.id.au>