Open Stack

On Fri, 2019-04-19 at 08:35 -0500, Matt Riedemann wrote:
> On 4/18/2019 3:51 AM, Natal Ngétal wrote:
> > Black is project to format Python code. It's more and more used by the python
> > 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 lose
> > 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. What
> > do you thinks about that? For example, we can introduce it on some projects, I
> > would volunteer to try on TripleO.
> 
> I'd be a -2 on this if proposed for nova. Screwing up git blame in a 
> 10-year old project is a non-starter for me, not to mention the issues 
> it would cause for backporting fixes to stable branch (which is already 
> hard enough given the rate of change we have in the project). Drive by 
> contributors might not care about that kind of thing but as a maintainer 
> of the project it's pretty critical to me.
> 
> I also can't buy the argument made elsewhere in this thread that this is 
> an issue turning away new contributors. Are there any new contributors 
> that can really stand up here and say they are leaving openstack 
> development because of code style/formatting inconsistencies? If this is 
> really an issue about reviewers -1ing changes for code style, then let's 
> call out those reviewers specifically and have a talk with them about 
> what is and isn't appropriate for a -1 on a review in openstack. We've 
> had these same nit pick review flame wars so may times over the years, 
> isn't there anything better for people to be worried about? How about 
> the gate burning down every few weeks? We don't have to care about code 
> style if we can't merge the beautifully auto-formatted code anyway.
so i tried using black over the last two days hacking on a personal project
and after trying it out my personal feeling on the topic have changed.
in comparison to lanagues such as c# c++ and go where indention is not
important at the lanague level the usefulness of black is severly limited by
the fact we use indentation instead of braces to denote scope.

in c++ i can write something totally unreadable but vaild like this

void dostuff ( int i){/* this is a function that returns the invocation of an inline lambda*/ return [&](){ return "this
is a string form a lambda";}(); }

and ill get back something that looks like this when i press ctrl+shift+i

LLVM style (my prefeffred style for c++)

void dostuff(int i) { /* this is a function that returns the invocation of an
                         inline lambda*/
  return [&]() { return "this is a string form a lambda"; }();
}

FILE style (this looks more like java to me or c)

void dostuff(int i)
{ /* this is a function that returns the invocation of an
     inline lambda*/
    return [&]()
    {
   
     return "this is a string form a lambda";
    }();
}


when i was using black however i kept typeing stuff that is valid python and
it just did not fix it at all and gave no warnings. so i found my self still having
to think about indention at which point it was more or less just simpeler to fix it myeslf.

so i think tools like autopep8 that dont really mess with formating but just fix pep8 violations and
nothing else are actully more uesful then black. im going to continue
to try it a bit more form my own stuff but honestly i ended up coming 180 on this topic after useing
it an i dont think it will help fix my personal issue with pep8 so i dont think it will add value
that can compensate for the negitive impacts on the git history.

>