The python black project.
On Thu, Apr 18, 2019 at 4:07 PM Monty Taylor <mordred at inaugust.com> wrote:
> On 4/18/19 7:04 PM, Clint Byrum wrote:
> > Quoting Natal NgÃ©tal (2019-04-18 01:51:47)
> >> Hi everyone,
> >> Black is project to format Python code. It's more and more used by the
> >> community. That can save time and harmonize the code. For example,
> simple quote
> >> versus double quote, that was not checked by pep8.i It's just an
> example of
> >> what make black With a pre-hook commit hook this will be also avoid to
> >> time with pep8 errors.
> >> Two links to see more:
> >> https://github.com/ambv/black
> >> https://www.mattlayman.com/blog/2018/python-code-black/
> >> I think it can be very interesting to start to use Black on OpenStack.
> >> do you thinks about that? For example, we can introduce it on some
> projects, I
> >> would volunteer to try on TripleO.
> > I've read the arguments in the thread, and I really appreciate
> > everyone's thoughtfulness here.
> > I just wanted to add that I have been using black for some internal
> > projects, and it is an absolute joy to forget about code formatting.
> > This is different than the pep8 checks. The git hook just does it, and
> > our CI confirms that you do it, and there's no more "oops I forgot
> > pep8".
> > I believe that the whitespace churn that folks are bringing up is being
> > overblown. This is a single, automatically produced diff, that while it
> > might hurt a little in git annotate and conflicts with in-flight patches
> > now, there is value, and there are mitigations, that make it worth it in
> > some cases.
> > The main value is that using an automatic formatter will ultimately lead
> > to less wasted test runs, less wasted developer time, and better diffs
> > with less conflicts later.
> > So while I appreciate the desire to not rock the boat, it might be that
> > the boat would go faster after some dead weight is dropped overboard,
> > and that new energy is applied to forward progress instead of "darn it,
> > now I have to think about how to fit this into 80 chars and parenthesis
> > and ..." >
> > Basically, weigh the one time cost vs. the ongoing savings, rather than
> > considering them separately.
> I think it's useful to point fingers at concrete things if we're going
> to weigh costs vs savings.
> Here is a patch:
> That runs openstacksdk through black and adds it to the pep8 tox env. I
> had to make two manual code changes, and add two pep8 exclusions.
> I also did -l 79 - because it's important.
> I'd get so many stackalytics points for the +55540, -39832 :)
I think that the generated code is generally about as easy to read as the
rest of the SDK project. That being said, it looks like black takes some of
the guess work out of the picture. I'd support using it. Personally, I am a
fan of the ~88 line length, but as long as black comes close to a
consistent 79 (note -l 79, according to the docs, does not guarantee no
lines longer than 79, but that it will make an attempt as long as no other
rules are violated) to make sure the folks who are more opinionated (hard
-1/-2 for a line-length change) are happy with using black, it should be
The change will be high-ish impact for backports (or require stable
branches to receive the same treatment) and could impact in-flight patches.
These are all things we've dealt with over and over in OpenStack.
Less guessing about code style and consistency is good in my opinion. It
tends to lead towards an easier to maintain code base. I also *really*
appreciate the simplicity of it being either a hook or baked into the pep8
check when run locally. I would advise that if black were to be run in the
gate as part of the pep8 check, it should raise an error if the code
changed between pre-black and post-black (change should always be done
local to the developer, before hitting gerrit unless we can have hooks in
gerrit to ensure consistency).
I vote monty get all the stackalytics points for all of the repos 1st run
of black commit (or maybe the openstack proposal bot if assigning it all to
Monty doesn't work.)
-------------- next part --------------
An HTML attachment was scrubbed...