The python black project.
ssbarnea at redhat.com
Thu Apr 18 09:52:18 UTC 2019
Black is a python code formatter, something similar to the older yapf.
I do like to avoid discussions about formatting in code reviews and prefer to let the linter take care of what could count as appointed.
My experience with yapf was far from idea as they decided to change formatting in a major way in their last *minor* version update, breaking havoc.
There is one reason why I did not even try black: it does require python3.6 !!!
While I do have a huge range of python version installed on my own dev machines, I cannot say the same about the average developer/contributor.
Considering that on CentOS-7 you can only get python3.5... this rest my case.
I do not want to limit the number of platform for contributors on any project, especially when we talk about one of the most basic/early check a developer would have to run on any change they make.
That is why -1 on black, and I guess it will be like this until we have CentOS 8 released. On the other hand, about yapf use I have mixed feelings.
I would rather prefer to see better adoption/coverage of: flake8, ansible-lint and yamllint -- preferably orchestrated via pre-commit as it lowers the execution time and disk footprint (sharing/caching identical linters between repositories) -- opposed to tox which does not shared anything between repositories. Tripleo-quickstart and tripleo-ci repositories are already using it and I did not hear many complaints, other than having to explain that pre-commit is does not require the use of a git hook.
Shortly, +2 on more pre-commit use, the tool not the git hook.
PS. Please do not bring the SCL into the thread, they do not provide a single command enablement of additional python interpreters (not in PATH).
> On 18 Apr 2019, at 09:57, Dmitry Tantsur <dtantsur at redhat.com> wrote:
> On 4/18/19 10:51 AM, Natal Ngétal wrote:
>> Hi everyone,
>> 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.
> I'm not sure what exactly Black does, but the last thing I want to see is patches changing between single and double quotes. If it's not the case or it can be turned off, I'm all for experimenting.
>> Two links to see more:
>> 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.
> Given it's a pre-commit hook, isn't it supposed to be done on developer's machines? If so, how do you see applying Black to the whole OpenStack?
>> My best regards
More information about the openstack-discuss