Agree with Florian that the progressive rollout is more trouble than it's
worth. Tangling up feature changes with whole file formatting will make it
harder to review changes, but will also be more difficult to use tools like
git blame.
As for disagreeing with some of Blacks choices - you learn very quickly to
live with those choices, and forget those choices. Any set of configuration
we could come up with for an existing tool would likely be bikeshedded to
death and nothing would eventuate.
For line lengths, projects I work on set Black to 100 columns, but flake8
line length is capped to 120. This lets some long strings (black doesn't
break long strings over multiple lines) get past flake8 without being over
the top.
I'm in favour of using blacks double quotes for strings. I **hated** this
decision when it was first made, but have seriously come around to it, and
prefer it aesthetically too. Consistency with other projects (most big
projects are adopting black) I feel is a good goal. The diff is already
going to be huge, there's not much value in protecting a few strings.
Finally, there are some tricks you pick up if black fights you on some
decisions. To use Berkers example:
TIME_INPUT_FORMATS = [
'%H:%M:%S', # '14:30:59'
'%H:%M:%S.%f', # '14:30:59.000200'
'%H:%M', # '14:30'
]
TIME_INPUT_FORMATS = ['%H:%M:%S', '%H:%M:%S.%f', '%H:%M'] # '14:30:59'
# '14:30:59.000200' # '14:30'
Break each individual format into its own variable, with appropriate
comment, and add the variables to the list.
HMS = "%H:%M:%S" # 14:30:59
HMSF = ".."
HM = ".."
TIME_INPUT_FORMATS = [HMS, HMSF, HM]
Obviously just an example, but something to keep in mind.
On Sunday, 14 April 2019 20:20:31 UTC+10, Florian Apolloner wrote:
>
> Hi,
>
> On Sunday, April 14, 2019 at 10:22:46 AM UTC+2, Curtis Maloney wrote:
>>
>> Can such a tool be automated into, say, github in a way that doesn't
>> create extra commit noise?
>>
>
> Probably, but after blacking (is that even a word ;)) the codebase once
> there shouldn't be much commit noise.
>
> I side with those who favour a progressive solution, whereby new code
>> only has the new tool applied.
>>
>
> I think that would make it hard on tools like git-hyper-blame which allow
> one to skip revisions. Also you cannot just run black over changes, the
> minimal unit is one file as far as I am aware. Which would make PR very
> very hard to review because you'd have a bunch of syntax changes next to
> real changes.
>
> In my experience with using black [we use it at work], there are
>> numerous choices (including those demonstrated in this list already)
>> where it can significantly _increase_ the cognitive load in simply
>> parsing the code.
>>
>
> Generally I am okay with the way black formats code. But I have to admit
> that for some very tricky codepaths I tend to turn it off from time to
> time. That does not happen very often though.
>
> As simple as black can make the job of code formatting, I feel I'd
>> rather see a different tool that retained the benefits of "trivial code
>> reformatting", but still allowed us to retain some of Django's existing
>> code formatting rules.
>>
>
> Open to suggestions, did you just offer to write one :)
>
> (An interesting [and defensible] choice, we had a module with a lot of
>> strings wrapped across lines. black opted to push them onto the same
>> line, but NOT to merge them. This is because in Python prior to 3.7, it
>> would have altered the generated AST - one of the guides black uses)
>>
>
> We can and should fix those occurrences in our codebase then I guess.
>
> Cheers,
> Florian
>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/8b81a047-babe-42d0-97f5-3af5f6b264fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
