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. 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. My best regards
Hi, 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:
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.
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? Dmitry
My best regards
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@redhat.com> wrote:
Hi,
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: 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.
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?
Dmitry
My best regards
On 4/18/19 11:52 AM, Sorin Sbarnea wrote:
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.
That's what pep8 jobs are for. They cannot be replaced with a pre-commit hooks, because people who are mostly likely to screw up formatting are also most likely to not have it installed.
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.
You're welcome: https://github.com/dtantsur/config/blob/master/tasks/packages.yml#L56-L72 :)
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.
I think we already use flake8 openstack-wide, what will Black bring us in addition to that? Dmitry
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@redhat.com> wrote:
Hi,
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: 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.
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?
Dmitry
My best regards
On Thu, 2019-04-18 at 11:56 +0200, Dmitry Tantsur wrote:
On 4/18/19 11:52 AM, Sorin Sbarnea wrote:
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.
That's what pep8 jobs are for. They cannot be replaced with a pre- commit hooks, because people who are mostly likely to screw up formatting are also most likely to not have it installed.
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.
You're welcome: https://github.com/dtantsur/config/blob/master/tasks/packages.yml#L56-L72 :)
You've also got tox and virtualenvs in general, but I don't think this is a serious issue tbh...
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.
I think we already use flake8 openstack-wide, what will Black bring us in addition to that?
I've seen this used with packages such as tox and warehouse (the new code base for pypi.org). black is intended to be an opinionated code formatter and exposes no knobs to the user, meaning it's very much "their way or the highway". This makes it different from something like yapf, which exposes all these knobs and therefore allows for arguments about e.g. whether one should use single or double quotes. No configuration knobs means no ability to discuss these preferences, which for something as subjective as code formatting seems to be a good thing to me. Now, as to whether it's practical, you have to realize that for it to be of any use, black has to be run initially over your entire codebase and then rerun on each commit. The latter isn't an issue (we already run flake8 for this purpose) but I genuinely cannot see something like nova rewrapping every line of code (all 552,347 of them, if my quick check is correct), essentially breaking the ability to cleanly backport patches and get meaningful 'git blame' output simply to avoid the occasional debate about code formatting. I think adopting black for a _new_ project (or even a very small one) could be a great idea, but for something as large and cumbersome as nova (or neutron, glance, cinder, some of the oslo libraries, etc.), maaaaaybe not. Stephen PS: As an aside, I would like to see something like black provided as part of the Python standard library to settle formatting issues for once and for all and help ensure that a minimum standard is set for most code you'll find (though code quality covers far more than mere formatting). To the best of my knowledge, the gofmt tool in go(lang) fills this role but I really can't see that happening within Python any time soon.
Dmitry
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@redhat.com> wrote:
Hi,
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: 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.
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?
Dmitry
My best regards
On Thu, 18 Apr 2019, Stephen Finucane wrote:
Now, as to whether it's practical, you have to realize that for it to be of any use, black has to be run initially over your entire codebase and then rerun on each commit. The latter isn't an issue (we already run flake8 for this purpose) but I genuinely cannot see something like nova rewrapping every line of code (all 552,347 of them, if my quick check is correct), essentially breaking the ability to cleanly backport patches and get meaningful 'git blame' output simply to avoid the occasional debate about code formatting. I think adopting black for a _new_ project (or even a very small one) could be a great idea, but for something as large and cumbersome as nova (or neutron, glance, cinder, some of the oslo libraries, etc.), maaaaaybe not.
Exactly this. Introducing black to an existing project with a long history is pretty much a non-starter. The fact that it provides no knobs is, as you say, a feature (everyone must must bow to the same evil dictator). -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
On 4/18/19 12:46 PM, Chris Dent wrote:
On Thu, 18 Apr 2019, Stephen Finucane wrote:
Now, as to whether it's practical, you have to realize that for it to be of any use, black has to be run initially over your entire codebase and then rerun on each commit. The latter isn't an issue (we already run flake8 for this purpose) but I genuinely cannot see something like nova rewrapping every line of code (all 552,347 of them, if my quick check is correct), essentially breaking the ability to cleanly backport patches and get meaningful 'git blame' output simply to avoid the occasional debate about code formatting. I think adopting black for a _new_ project (or even a very small one) could be a great idea, but for something as large and cumbersome as nova (or neutron, glance, cinder, some of the oslo libraries, etc.), maaaaaybe not.
Exactly this. Introducing black to an existing project with a long history is pretty much a non-starter.
The fact that it provides no knobs is, as you say, a feature (everyone must must bow to the same evil dictator).
... except when somebody blocks the adoption completely because of a dislike for some aspect :) This is where a tool officially blessed by the Python core team would come handier (like 'go fmt', 'cargo fmt', etc).
On Thu, 2019-04-18 at 12:53 +0200, Dmitry Tantsur wrote:
On 4/18/19 12:46 PM, Chris Dent wrote:
On Thu, 18 Apr 2019, Stephen Finucane wrote:
Now, as to whether it's practical, you have to realize that for it to be of any use, black has to be run initially over your entire codebase and then rerun on each commit. The latter isn't an issue (we already run flake8 for this purpose) but I genuinely cannot see something like nova rewrapping every line of code (all 552,347 of them, if my quick check is correct), essentially breaking the ability to cleanly backport patches and get meaningful 'git blame' output simply to avoid the occasional debate about code formatting. I think adopting black for a _new_ project (or even a very small one) could be a great idea, but for something as large and cumbersome as nova (or neutron, glance, cinder, some of the oslo libraries, etc.), maaaaaybe not.
Exactly this. Introducing black to an existing project with a long history is pretty much a non-starter.
The fact that it provides no knobs is, as you say, a feature (everyone must must bow to the same evil dictator).
... except when somebody blocks the adoption completely because of a dislike for some aspect :) This is where a tool officially blessed by the Python core team would come handier (like 'go fmt', 'cargo fmt', etc). yes but it does not need to be the python core team that blesses it. for yapf which is based on clang-format you can provide project specific styles.
so we could have an openstack style that we applied however to do that i think this would need the help of the TC and consultation with all projects to a.) agree on a tool b.) agree on a style config and c.) agree on an implementation path. indivigual projects, espically small/new ones could standardise on a tool/style themselves but in the absence of a blessed formater form the Python core team if we wanted to adopt this in openstack as a whole it would have to become part of the PTI which would require TC involvement and comunity buy in.
On Thu, 2019-04-18 at 11:56 +0200, Dmitry Tantsur wrote:
On 4/18/19 11:52 AM, Sorin Sbarnea wrote:
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.
That's what pep8 jobs are for. They cannot be replaced with a pre- commit hooks, because people who are mostly likely to screw up formatting are also most likely to not have it installed.
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.
You're welcome: https://github.com/dtantsur/config/blob/master/tasks/packages.yml#L56-L72 :)
You've also got tox and virtualenvs in general, but I don't think this is a serious issue tbh...
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.
I think we already use flake8 openstack-wide, what will Black bring us in addition to that?
I've seen this used with packages such as tox and warehouse (the new code base for pypi.org). black is intended to be an opinionated code formatter and exposes no knobs to the user, meaning it's very much "their way or the highway". This makes it different from something like yapf, which exposes all these knobs and therefore allows for arguments about e.g. whether one should use single or double quotes. No configuration knobs means no ability to discuss these preferences, which for something as subjective as code formatting seems to be a good thing to me.
Now, as to whether it's practical, you have to realize that for it to be of any use, black has to be run initially over your entire codebase and then rerun on each commit. The latter isn't an issue (we already run flake8 for this purpose) but I genuinely cannot see something like nova rewrapping every line of code (all 552,347 of them, if my quick check is correct), essentially breaking the ability to cleanly backport patches and get meaningful 'git blame' output simply to avoid the occasional debate about code formatting. i get the git blame argument but i really hope the rest are not valid.
On Thu, 2019-04-18 at 11:33 +0100, Stephen Finucane wrote: that would be a seriously depressing situation as it means we can never automate away the formatting of our code which we really should. the fact we have automated checking but not fixing of code style is one of the most irritating parts of working with openstack development personally. it might be worth seeing fi there is a way to use yapf or black but only on the functions being modifed in a current patch? in other word find a way to do it incrementally.
I think adopting black for a _new_ project (or even a very small one) could be a great idea, but for something as large and cumbersome as nova (or neutron, glance, cinder, some of the oslo libraries, etc.), maaaaaybe not. i didnt actully know there were tool like this for python. i have wanted to add something similar to os-vif since it was created but the best i could comeup with was "maybe we can convice clangfromat to work"
Stephen
PS: As an aside, I would like to see something like black provided as part of the Python standard library to settle formatting issues for once and for all and help ensure that a minimum standard is set for most code you'll find (though code quality covers far more than mere formatting). To the best of my knowledge, the gofmt tool in go(lang) fills this role but I really can't see that happening within Python any time soon. +42 this is why i would like something like this to be a thing in the openstack ecosystem at least but yes i also agree with this idea and that it does not seam to be happening in the sort term :(
Dmitry
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@redhat.com> wrote:
Hi,
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: 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.
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?
Dmitry
My best regards
On 2019-04-18 11:55:11 +0100 (+0100), Sean Mooney wrote: [...]
the fact we have automated checking but not fixing of code style is one of the most irritating parts of working with openstack development personally. [...]
Contrary to popular belief, the primary benefit we get from automated style checks is *not* code consistency, it's reducing the number of arguments and conflicting style recommendations reviewers tend to have when we leave it up to them to decide how they think someone else's patch should be written. With a style checker in place we can more reliably tell reviewers to focus on function rather than form, and to please keep their opinions about indentation and quote choices to themselves. Between projects (and even between branches of the same projects), we already have a variety of linters at varying versions with a slew of different per-project skips, choice of additional plugins and so on. Code styles across the many hundreds of official Git repositories in OpenStack aren't consistent and never have been, but we still manage to produce much more readable, maintainable code than most free/libre open source projects I've encountered. I for one am willing to call that a win, and would prefer to focus on producing software rather than producing whitespace and punctuation. -- Jeremy Stanley
Hi,
Wiadomość napisana przez Stephen Finucane <sfinucan@redhat.com> w dniu 18.04.2019, o godz. 12:33:
On Thu, 2019-04-18 at 11:56 +0200, Dmitry Tantsur wrote:
On 4/18/19 11:52 AM, Sorin Sbarnea wrote:
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.
That's what pep8 jobs are for. They cannot be replaced with a pre- commit hooks, because people who are mostly likely to screw up formatting are also most likely to not have it installed.
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.
You're welcome: https://github.com/dtantsur/config/blob/master/tasks/packages.yml#L56-L72 :)
You've also got tox and virtualenvs in general, but I don't think this is a serious issue tbh...
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.
I think we already use flake8 openstack-wide, what will Black bring us in addition to that?
I've seen this used with packages such as tox and warehouse (the new code base for pypi.org). black is intended to be an opinionated code formatter and exposes no knobs to the user, meaning it's very much "their way or the highway". This makes it different from something like yapf, which exposes all these knobs and therefore allows for arguments about e.g. whether one should use single or double quotes. No configuration knobs means no ability to discuss these preferences, which for something as subjective as code formatting seems to be a good thing to me.
Now, as to whether it's practical, you have to realize that for it to be of any use, black has to be run initially over your entire codebase and then rerun on each commit. The latter isn't an issue (we already run flake8 for this purpose) but I genuinely cannot see something like nova rewrapping every line of code (all 552,347 of them, if my quick check is correct), essentially breaking the ability to cleanly backport patches and get meaningful 'git blame' output simply to avoid the occasional debate about code formatting. I think adopting black for a _new_ project (or even a very small one) could be a great idea, but for something as large and cumbersome as nova (or neutron, glance, cinder, some of the oslo libraries, etc.), maaaaaybe not.
+100 to this. Resolving manually many conflicts between master and stable branches just because e.g. quoting was changed doesn’t seems like good thing :)
Stephen
PS: As an aside, I would like to see something like black provided as part of the Python standard library to settle formatting issues for once and for all and help ensure that a minimum standard is set for most code you'll find (though code quality covers far more than mere formatting). To the best of my knowledge, the gofmt tool in go(lang) fills this role but I really can't see that happening within Python any time soon.
Dmitry
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@redhat.com> wrote:
Hi,
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: 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.
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?
Dmitry
My best regards
— Slawek Kaplonski Senior software engineer Red Hat
On Thu, 2019-04-18 at 13:02 +0200, Slawomir Kaplonski wrote:
Hi,
Wiadomość napisana przez Stephen Finucane <sfinucan@redhat.com> w dniu 18.04.2019, o godz. 12:33:
On Thu, 2019-04-18 at 11:56 +0200, Dmitry Tantsur wrote:
On 4/18/19 11:52 AM, Sorin Sbarnea wrote:
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.
That's what pep8 jobs are for. They cannot be replaced with a pre- commit hooks, because people who are mostly likely to screw up formatting are also most likely to not have it installed.
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.
You're welcome: https://github.com/dtantsur/config/blob/master/tasks/packages.yml#L56-L72 :)
You've also got tox and virtualenvs in general, but I don't think this is a serious issue tbh...
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.
I think we already use flake8 openstack-wide, what will Black bring us in addition to that?
I've seen this used with packages such as tox and warehouse (the new code base for pypi.org). black is intended to be an opinionated code formatter and exposes no knobs to the user, meaning it's very much "their way or the highway". This makes it different from something like yapf, which exposes all these knobs and therefore allows for arguments about e.g. whether one should use single or double quotes. No configuration knobs means no ability to discuss these preferences, which for something as subjective as code formatting seems to be a good thing to me.
Now, as to whether it's practical, you have to realize that for it to be of any use, black has to be run initially over your entire codebase and then rerun on each commit. The latter isn't an issue (we already run flake8 for this purpose) but I genuinely cannot see something like nova rewrapping every line of code (all 552,347 of them, if my quick check is correct), essentially breaking the ability to cleanly backport patches and get meaningful 'git blame' output simply to avoid the occasional debate about code formatting. I think adopting black for a _new_ project (or even a very small one) could be a great idea, but for something as large and cumbersome as nova (or neutron, glance, cinder, some of the oslo libraries, etc.), maaaaaybe not.
+100 to this. Resolving manually many conflicts between master and stable branches just because e.g. quoting was changed doesn’t seems like good thing :) you realise if we also applied this to the stable branches too we would never need to resolve a merge conflict due to formating again or correct any pep8/style issues on backports. but yes its a valid concern.
i guess the general feedback so far has been unless there is a way to do it incrementally this is a non starter. that is sad but if that is how people feel ill let this to the original poster to fight.
Stephen
PS: As an aside, I would like to see something like black provided as part of the Python standard library to settle formatting issues for once and for all and help ensure that a minimum standard is set for most code you'll find (though code quality covers far more than mere formatting). To the best of my knowledge, the gofmt tool in go(lang) fills this role but I really can't see that happening within Python any time soon.
Dmitry
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@redhat.com> wrote:
Hi,
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: 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.
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?
Dmitry
My best regards
— Slawek Kaplonski Senior software engineer Red Hat
Hi all, In general, I would like to have black formatter for the OpenStack code. I agree with the points mentioned above about git blame. Also, I really don't want to have dozens of patches just to address few more black rules in the existing code base. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Thu, Apr 18, 2019 at 2:18 PM Sean Mooney <smooney@redhat.com> wrote:
Hi,
Wiadomość napisana przez Stephen Finucane <sfinucan@redhat.com> w dniu 18.04.2019, o godz. 12:33:
On Thu, 2019-04-18 at 11:56 +0200, Dmitry Tantsur wrote:
On 4/18/19 11:52 AM, Sorin Sbarnea wrote:
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.
That's what pep8 jobs are for. They cannot be replaced with a pre- commit hooks, because people who are mostly likely to screw up formatting are also most likely to not have it installed.
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.
You're welcome:
https://github.com/dtantsur/config/blob/master/tasks/packages.yml#L56-L72 :)
You've also got tox and virtualenvs in general, but I don't think this is a serious issue tbh...
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
On Thu, 2019-04-18 at 13:02 +0200, Slawomir Kaplonski wrote: 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.
I think we already use flake8 openstack-wide, what will Black bring us in addition to that?
I've seen this used with packages such as tox and warehouse (the new code base for pypi.org). black is intended to be an opinionated code formatter and exposes no knobs to the user, meaning it's very much "their way or the highway". This makes it different from something like yapf, which exposes all these knobs and therefore allows for arguments about e.g. whether one should use single or double quotes. No configuration knobs means no ability to discuss these preferences, which for something as subjective as code formatting seems to be a good thing to me.
Now, as to whether it's practical, you have to realize that for it to be of any use, black has to be run initially over your entire codebase and then rerun on each commit. The latter isn't an issue (we already run flake8 for this purpose) but I genuinely cannot see something like nova rewrapping every line of code (all 552,347 of them, if my quick check is correct), essentially breaking the ability to cleanly backport patches and get meaningful 'git blame' output simply to avoid the occasional debate about code formatting. I think adopting black for a _new_ project (or even a very small one) could be a great idea, but for something as large and cumbersome as nova (or neutron, glance, cinder, some of the oslo libraries, etc.), maaaaaybe not.
+100 to this. Resolving manually many conflicts between master and stable branches just because e.g. quoting was changed doesn’t seems like good thing :) you realise if we also applied this to the stable branches too we would never need to resolve a merge conflict due to formating again or correct any pep8/style issues on backports. but yes its a valid concern.
i guess the general feedback so far has been unless there is a way to do it incrementally this is a non starter. that is sad but if that is how people feel ill let this to the original poster to fight.
Stephen
PS: As an aside, I would like to see something like black provided as part of the Python standard library to settle formatting issues for once and for all and help ensure that a minimum standard is set for most code you'll find (though code quality covers far more than mere formatting). To the best of my knowledge, the gofmt tool in go(lang) fills this role but I really can't see that happening within Python any time soon.
Dmitry
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@redhat.com> wrote:
Hi,
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: > 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.
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?
Dmitry
> My best regards
— Slawek Kaplonski Senior software engineer Red Hat
On Thu, Apr 18, 2019 at 2:13 PM Ivan Kolodyazhny <e0ne@e0ne.info> wrote:
In general, I would like to have black formatter for the OpenStack code. Maybe we can use black formatter on a new projects.
I agree with the points mentioned above about git blame. Also, I really don't want to have dozens of patches just to address few more black rules in the existing code base. I understand what you mean. Merge and backport problem.
On Thu, 2019-04-18 at 11:56 +0200, Dmitry Tantsur wrote:
On 4/18/19 11:52 AM, Sorin Sbarnea wrote:
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.
That's what pep8 jobs are for. They cannot be replaced with a pre-commit hooks, because people who are mostly likely to screw up formatting are also most likely to not have it installed. im not sure about the later point. i mess up pep8 with parctially every patch and i have worked on openstack/python for almost 6 years at this point but i agree it cant replace the pep8 job but we shoudl also have a black job.
also we could easily provide a tox -e black to do the formatting.
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.
you can get 3.6 on centos. that is what my dev vms ues by default. python3.6 is shiped in the epel repos and centos defaults to python 3.4 py3.5 was the version i tought you could not easily install on centos7
You're welcome: https://github.com/dtantsur/config/blob/master/tasks/packages.yml#L56-L72 :)
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.
I think we already use flake8 openstack-wide, what will Black bring us in addition to that?
i have not looked at black but if its anything like clang-format or go's gofmt tool there is a lot to be gained by haveing a tool format all code in a repo to follow a project/langage specific coding style with 0 human interaction required. i we were to apply this to openstack we woudl need a singel mechanical commit that used black to reformat all code in a repo which also intoduces a black gate jobs. the black gate job going forward would reject any patch that would require black to modify it. e.g. the job woudl take the change run black and check git diff to see if anything changed. if it did fail if it didn't pass.
Dmitry
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@redhat.com> wrote:
Hi,
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: 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.
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?
Dmitry
My best regards
I think we already use flake8 openstack-wide, what will Black bring us in addition to that?
Dmitry
Based on my quick test, it would bring us code churn of changing ' to " and flake8 errors due to unwrapping lines and making them longer than 80 characters. I like the idea of code consistency. But having a tool automatically do it without being able to tweak the settings, and having defaults do things that introduce pep8 errors, seems like a non-starter. And as mentioned elsewhere, introducing something like this to a long established code base has a lot of problems. Maybe new projects just starting off may want to investigate further, but running on most projects could be a nightmare. Sean
On 4/18/19 1:45 PM, Sean McGinnis wrote:
I think we already use flake8 openstack-wide, what will Black bring us in addition to that?
Dmitry
Based on my quick test, it would bring us code churn of changing ' to " and flake8 errors due to unwrapping lines and making them longer than 80 characters.
I like the idea of code consistency. But having a tool automatically do it without being able to tweak the settings, and having defaults do things that introduce pep8 errors, seems like a non-starter.
And as mentioned elsewhere, introducing something like this to a long established code base has a lot of problems. Maybe new projects just starting off may want to investigate further, but running on most projects could be a nightmare.
I agree. I actually looked at black a little while ago for openstacksdk - because I do like me some strict style rules. The long-line-length sucked, although making a tox env that passes a reasonable line-length worked around that. The biggest problem is that, even in a pretty clean codebase that already tries to follow a lot of what black likes (line breaks after brackets - yes please!) - the churn was MASSIVE and really just not worth it. If we were starting OpenStack from-scratch today, I'd recommend we adopt it. But we're not. Also - if new projects decided to adopt black, we'd wind up with two conflicting codestyles across OpenStack, which is one of the things our long-standing gating on pep8 is supposed to prevent. I don't think it's a good idea for OpenStack to _partially_ adopt black. Monty
On 4/18/19 9:00 AM, Monty Taylor wrote:
On 4/18/19 1:45 PM, Sean McGinnis wrote:
I think we already use flake8 openstack-wide, what will Black bring us in addition to that?
Dmitry
Based on my quick test, it would bring us code churn of changing ' to " and flake8 errors due to unwrapping lines and making them longer than 80 characters.
I like the idea of code consistency. But having a tool automatically do it without being able to tweak the settings, and having defaults do things that introduce pep8 errors, seems like a non-starter.
And as mentioned elsewhere, introducing something like this to a long established code base has a lot of problems. Maybe new projects just starting off may want to investigate further, but running on most projects could be a nightmare.
I agree.
I actually looked at black a little while ago for openstacksdk - because I do like me some strict style rules. The long-line-length sucked, although making a tox env that passes a reasonable line-length worked around that.
The biggest problem is that, even in a pretty clean codebase that already tries to follow a lot of what black likes (line breaks after brackets - yes please!) - the churn was MASSIVE and really just not worth it.
If we were starting OpenStack from-scratch today, I'd recommend we adopt it. But we're not.
Also - if new projects decided to adopt black, we'd wind up with two conflicting codestyles across OpenStack, which is one of the things our long-standing gating on pep8 is supposed to prevent. I don't think it's a good idea for OpenStack to _partially_ adopt black.
++ Conflicting code styles is just going to raise the cognitive bar for contributors. If black's conventions are too restrictive, but we still want more consistency, someone can drive an effort to start writing down conventions we, as in OpenStack, think are important. Maybe our desired conventions are closer to black's than we originally anticipated. Maybe they're not. Regardless, it seems the underlying issue is applying any convention to a large codebase.
Monty
On Thu, Apr 18, 2019, at 9:09 AM, Lance Bragstad wrote:
On 4/18/19 9:00 AM, Monty Taylor wrote:
On 4/18/19 1:45 PM, Sean McGinnis wrote:
I think we already use flake8 openstack-wide, what will Black bring us in addition to that?
Dmitry
Based on my quick test, it would bring us code churn of changing ' to " and flake8 errors due to unwrapping lines and making them longer than 80 characters.
I like the idea of code consistency. But having a tool automatically do it without being able to tweak the settings, and having defaults do things that introduce pep8 errors, seems like a non-starter.
And as mentioned elsewhere, introducing something like this to a long established code base has a lot of problems. Maybe new projects just starting off may want to investigate further, but running on most projects could be a nightmare.
I agree.
I actually looked at black a little while ago for openstacksdk - because I do like me some strict style rules. The long-line-length sucked, although making a tox env that passes a reasonable line-length worked around that.
The biggest problem is that, even in a pretty clean codebase that already tries to follow a lot of what black likes (line breaks after brackets - yes please!) - the churn was MASSIVE and really just not worth it.
If we were starting OpenStack from-scratch today, I'd recommend we adopt it. But we're not.
Also - if new projects decided to adopt black, we'd wind up with two conflicting codestyles across OpenStack, which is one of the things our long-standing gating on pep8 is supposed to prevent. I don't think it's a good idea for OpenStack to _partially_ adopt black.
++
Conflicting code styles is just going to raise the cognitive bar for contributors. If black's conventions are too restrictive, but we still want more consistency, someone can drive an effort to start writing down conventions we, as in OpenStack, think are important. Maybe our desired conventions are closer to black's than we originally anticipated. Maybe they're not.
Regardless, it seems the underlying issue is applying any convention to a large codebase.
I've not seen it mentioned in this thread yet, but I think it is a fairly important point: Black's conventions are rigid because Black aims to reduce merge conflicts and aid in code review by reducing diff sizes. The rules aren't arbitrary. I think if we were to use Black the aim would be to get these benefits and accept that it may not always format the code the way I (or you) want it. Also, I don't think we would continue to follow pep8 if we switched to Black. It is one or the other. That said I agree there would be a fairly high cost to convert an existing code base to it and I also agree we probably don't want to have inconsistent rules across repos. Another concern is that Black does apparently tweak rules over time which can lead to large sets of changes when Black updates. We have similar problems with pep8 tooling, but we can do fine grained rule ignore lists and avoid needing to incur massive churn all at once. Clark
On 4/18/19 6:20 PM, Clark Boylan wrote:
On Thu, Apr 18, 2019, at 9:09 AM, Lance Bragstad wrote:
On 4/18/19 9:00 AM, Monty Taylor wrote:
On 4/18/19 1:45 PM, Sean McGinnis wrote:
I think we already use flake8 openstack-wide, what will Black bring us in addition to that?
Dmitry
Based on my quick test, it would bring us code churn of changing ' to " and flake8 errors due to unwrapping lines and making them longer than 80 characters.
I like the idea of code consistency. But having a tool automatically do it without being able to tweak the settings, and having defaults do things that introduce pep8 errors, seems like a non-starter.
And as mentioned elsewhere, introducing something like this to a long established code base has a lot of problems. Maybe new projects just starting off may want to investigate further, but running on most projects could be a nightmare.
I agree.
I actually looked at black a little while ago for openstacksdk - because I do like me some strict style rules. The long-line-length sucked, although making a tox env that passes a reasonable line-length worked around that.
The biggest problem is that, even in a pretty clean codebase that already tries to follow a lot of what black likes (line breaks after brackets - yes please!) - the churn was MASSIVE and really just not worth it.
If we were starting OpenStack from-scratch today, I'd recommend we adopt it. But we're not.
Also - if new projects decided to adopt black, we'd wind up with two conflicting codestyles across OpenStack, which is one of the things our long-standing gating on pep8 is supposed to prevent. I don't think it's a good idea for OpenStack to _partially_ adopt black.
++
Conflicting code styles is just going to raise the cognitive bar for contributors. If black's conventions are too restrictive, but we still want more consistency, someone can drive an effort to start writing down conventions we, as in OpenStack, think are important. Maybe our desired conventions are closer to black's than we originally anticipated. Maybe they're not.
Regardless, it seems the underlying issue is applying any convention to a large codebase.
I've not seen it mentioned in this thread yet, but I think it is a fairly important point: Black's conventions are rigid because Black aims to reduce merge conflicts and aid in code review by reducing diff sizes. The rules aren't arbitrary. I think if we were to use Black the aim would be to get these benefits and accept that it may not always format the code the way I (or you) want it.
Also, I don't think we would continue to follow pep8 if we switched to Black. It is one or the other.
Won't it make OpenStack code more surprising for outside contributors? I think if something is worth following, it is PEP-8, since it's a Python standard.
That said I agree there would be a fairly high cost to convert an existing code base to it and I also agree we probably don't want to have inconsistent rules across repos.
Another concern is that Black does apparently tweak rules over time which can lead to large sets of changes when Black updates. We have similar problems with pep8 tooling, but we can do fine grained rule ignore lists and avoid needing to incur massive churn all at once.
This can become a big issue, actually. We'd probably have to pin Black to an exact version (excluding it from global-requirements).
Clark
On 4/18/19 6:20 PM, Clark Boylan wrote:
On Thu, Apr 18, 2019, at 9:09 AM, Lance Bragstad wrote:
On 4/18/19 9:00 AM, Monty Taylor wrote:
On 4/18/19 1:45 PM, Sean McGinnis wrote:
I think we already use flake8 openstack-wide, what will Black bring us in addition to that?
Dmitry
Based on my quick test, it would bring us code churn of changing ' to " and flake8 errors due to unwrapping lines and making them longer than 80 characters.
I like the idea of code consistency. But having a tool automatically do it without being able to tweak the settings, and having defaults do things that introduce pep8 errors, seems like a non-starter.
And as mentioned elsewhere, introducing something like this to a long established code base has a lot of problems. Maybe new projects just starting off may want to investigate further, but running on most projects could be a nightmare.
I agree.
I actually looked at black a little while ago for openstacksdk - because I do like me some strict style rules. The long-line-length sucked, although making a tox env that passes a reasonable line-length worked around that.
The biggest problem is that, even in a pretty clean codebase that already tries to follow a lot of what black likes (line breaks after brackets - yes please!) - the churn was MASSIVE and really just not worth it.
If we were starting OpenStack from-scratch today, I'd recommend we adopt it. But we're not.
Also - if new projects decided to adopt black, we'd wind up with two conflicting codestyles across OpenStack, which is one of the things our long-standing gating on pep8 is supposed to prevent. I don't think it's a good idea for OpenStack to _partially_ adopt black.
++
Conflicting code styles is just going to raise the cognitive bar for contributors. If black's conventions are too restrictive, but we still want more consistency, someone can drive an effort to start writing down conventions we, as in OpenStack, think are important. Maybe our desired conventions are closer to black's than we originally anticipated. Maybe they're not.
Regardless, it seems the underlying issue is applying any convention to a large codebase.
I've not seen it mentioned in this thread yet, but I think it is a fairly important point: Black's conventions are rigid because Black aims to reduce merge conflicts and aid in code review by reducing diff sizes. The rules aren't arbitrary. I think if we were to use Black the aim would be to get these benefits and accept that it may not always format the code the way I (or you) want it.
Also, I don't think we would continue to follow pep8 if we switched to Black. It is one or the other.
Won't it make OpenStack code more surprising for outside contributors? I think if something is worth following, it is PEP-8, since it's a Python standard.
On Thu, 2019-04-18 at 18:28 +0200, Dmitry Tantsur wrote: pep8 is a set of guidelines that are intened for developers to use themsevels to improve the readablity of there own code. it was never intended to be something to force on others and it very clearly give peopel the fredom to not follow all of it. https://www.python.org/dev/peps/pep-0008/#a-foolish-consistency-is-the-hobgo... having some divergence might be unfamilar but we already diverge today. also pep8 leave several ways to do some things def func(arg1, arg2, arg3): pass def func(arg1, arg2, arg3): pass def func( arg1, arg2, arg3): pass all 3 of those are pep8 complient functions black say the last two are dumb becasue you are wasting virticl space making diffs bigger and will handel the wraping as need to also stay withind the default of 88 charaters. you can override it to 79 if we wanted too but even pep8 says up to 99 charater is fine if that is what teams agree too. https://www.python.org/dev/peps/pep-0008/#maximum-line-length
That said I agree there would be a fairly high cost to convert an existing code base to it and I also agree we probably don't want to have inconsistent rules across repos. Another concern is that Black does apparently tweak rules over time which can lead to large sets of changes when Black updates. We have similar problems with pep8 tooling, but we can do fine grained rule ignore lists and avoid needing to incur massive churn all at once. This can become a big issue, actually. We'd probably have to pin Black to an exact version (excluding it from global-requirements). Clark
On 4/18/2019 11:08 AM, Lance Bragstad wrote:
If black's conventions are too restrictive, but we still want more consistency, someone can drive an effort to start writing down conventions we, as in OpenStack, think are important.
Seems we've all forgotten openstack already has a project to do this: http://git.openstack.org/cgit/openstack-dev/hacking/tree/README.rst It's just that people probably don't do many new hacking checks in their projects anymore, or they don't think about "upstreaming" them to the hacking library and then percolating those rules out to all other projects. Also, each project can pick and choose which hacking checks they want to adopt, and enforce them gradually rather than all at once - which is one of the knocks I'm reading about Black in this thread. -- Thanks, Matt
On 4/18/2019 11:08 AM, Lance Bragstad wrote:
If black's conventions are too restrictive, but we still want more consistency, someone can drive an effort to start writing down conventions we, as in OpenStack, think are important.
Seems we've all forgotten openstack already has a project to do this:
http://git.openstack.org/cgit/openstack-dev/hacking/tree/README.rst hacking was in the back of my mind too
It's just that people probably don't do many new hacking checks in their projects anymore, or they don't think about "upstreaming" them to the hacking library and then percolating those rules out to all other projects.
Also, each project can pick and choose which hacking checks they want to adopt, and enforce them gradually rather than all at once - which is one of the knocks I'm reading about Black in this thread.
On Thu, 2019-04-18 at 12:26 -0500, Matt Riedemann wrote: they can but hacking unless i missed it cant reformat your code to make it complient. i spend a non trivial amount of time just getting pep8 to be happy and even then i often miss things. i which that could be automated away but it seam apparent that unless that can be dont incremetally its not going to happen in nova.
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 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'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.
in general, i tend to think that adding more tooling to help the code become more consistent is a good thing for the community and especially people who are new to a project. there is one point i'd like to mention in response to something that Clint said. On Thu, Apr 18, 2019 at 3:10 PM Clint Byrum <clint@fewbar.com> wrote:
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 think having this be automated is something that throws my personal workflow off, and i hope that if it does become enshrined as a commit hook that we give developers the tooling to test locally before pushing for review. i like to be able to test all my changes locally before i push for review, if there is a tool in between me and the review and that changes my code then i /definitely/ want to be able to test these changes before i go to review. i imagine this is not a big deal, others have mentioned adding a tox target or similar. i just wanted to bring it up as a point to consider in this process. peace o/
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 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'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: https://review.openstack.org/653876 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 :) Monty
On Thu, Apr 18, 2019 at 4:07 PM Monty Taylor <mordred@inaugust.com> 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 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
On 4/18/19 7:04 PM, Clint Byrum wrote: python 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:
https://review.openstack.org/653876
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 :)
Monty
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 fine. 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.) --Morgan
On 4/19/19 1:05 AM, Monty Taylor 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 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'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:
https://review.openstack.org/653876
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 quite hate some of the changes it made, e.g. https://review.opendev.org/#/c/653876/1/openstack/baremetal/v1/_proxy.py@296 is a horrible waste of screen space, while https://review.opendev.org/#/c/653876/1/openstack/baremetal/v1/node.py@267 also looks pretty weird to me.
I also did -l 79 - because it's important.
I'd get so many stackalytics points for the +55540, -39832 :)
Monty
On Tue, 2019-04-23 at 15:29 +0200, Dmitry Tantsur wrote:
On 4/19/19 1:05 AM, Monty Taylor 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 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'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:
https://review.openstack.org/653876
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 quite hate some of the changes it made, e.g. https://review.opendev.org/#/c/653876/1/openstack/baremetal/v1/_proxy.py@296 is a horrible waste of screen space, while https://review.opendev.org/#/c/653876/1/openstack/baremetal/v1/node.py@267 also looks pretty weird to me.
ya i think i could get more behind autopep8 or yapf. running autopep8 on nova https://review.opendev.org/#/c/655171/ has very little change litrally adding 1 empty new line to to 102 files that with almost 0 other code curn. using autopep8 however would fix any actul pep8 issue in new patches automatically without the downsides of black.
I also did -l 79 - because it's important.
I'd get so many stackalytics points for the +55540, -39832 :)
Monty
On 2019-04-23 15:39:48 +0100 (+0100), Sean Mooney wrote: [...]
ya i think i could get more behind autopep8 or yapf. running autopep8 on nova https://review.opendev.org/#/c/655171/ has very little change
litrally adding 1 empty new line to to 102 files that with almost 0 other code curn. using autopep8 however would fix any actul pep8 issue in new patches automatically without the downsides of black. [...]
I'm more concerned with the implementation logistics, honestly. How do you propose going about this? If you want to use a Git commit or pre-commit hook then you can do it already--go for it. If you want everyone proposing changes to the same repository to use the same commit hook, that becomes a distribution/enforcement challenge to solve. If you want it somehow enforced on the receiving end of the push, say with a receive hook, that's brittle and will have side effects such as invalidating signed commits (which we're able to support at the moment). Basically the only friendly and reliable way to enforce this centrally is to have the desired style conventions validated upon receipt by the code review system and the results reported back to the committer. This is exactly what we already do today. There are of course also ways to reject the change with a push error so that the committer has to amend and push again, but that's not easy to manage across different projects and also doesn't solve your desire to "not need to think about code style" (paraphrased). There is also the possibility that you simply run a periodic autopep8 job against the codebase and have that job propose a commit to the repository to apply code style changes if there are any, but that's a bit of a messy hack as well. -- Jeremy Stanley
I've wondered for a while if you could automate the automation. So, like, run the autoformatter and feed back the generated patch back to the developer in a way they can easily accept it. Like, making a pr against their pr with the formatting fixes, so that they can easily merge it in. Thanks, Kevin ________________________________________ From: Jeremy Stanley [fungi@yuggoth.org] Sent: Tuesday, April 23, 2019 11:39 AM To: openstack-discuss@lists.openstack.org Subject: Re: The python black project. On 2019-04-23 15:39:48 +0100 (+0100), Sean Mooney wrote: [...]
ya i think i could get more behind autopep8 or yapf. running autopep8 on nova https://review.opendev.org/#/c/655171/ has very little change
litrally adding 1 empty new line to to 102 files that with almost 0 other code curn. using autopep8 however would fix any actul pep8 issue in new patches automatically without the downsides of black. [...]
I'm more concerned with the implementation logistics, honestly. How do you propose going about this? If you want to use a Git commit or pre-commit hook then you can do it already--go for it. If you want everyone proposing changes to the same repository to use the same commit hook, that becomes a distribution/enforcement challenge to solve. If you want it somehow enforced on the receiving end of the push, say with a receive hook, that's brittle and will have side effects such as invalidating signed commits (which we're able to support at the moment). Basically the only friendly and reliable way to enforce this centrally is to have the desired style conventions validated upon receipt by the code review system and the results reported back to the committer. This is exactly what we already do today. There are of course also ways to reject the change with a push error so that the committer has to amend and push again, but that's not easy to manage across different projects and also doesn't solve your desire to "not need to think about code style" (paraphrased). There is also the possibility that you simply run a periodic autopep8 job against the codebase and have that job propose a commit to the repository to apply code style changes if there are any, but that's a bit of a messy hack as well. -- Jeremy Stanley
On Tue, 2019-04-23 at 19:06 +0000, Fox, Kevin M wrote:
I've wondered for a while if you could automate the automation. So, like, run the autoformatter and feed back the generated patch back to the developer in a way they can easily accept it. Like, making a pr against their pr with the formatting fixes, so that they can easily merge it in. well you can with a pre-commit hook + a job chagne to enforce it. so pre-commit hook runs an autopep8 tox env. if the tox run modifies any files fail the commit. in the gate we also assert the same thing in the pep8 job. and retrun the diff in the logs somewhere
anyway i know not everyone would be on board with that but its what i would proably do if i was starting proejct from scratch.
Thanks, Kevin ________________________________________ From: Jeremy Stanley [fungi@yuggoth.org] Sent: Tuesday, April 23, 2019 11:39 AM To: openstack-discuss@lists.openstack.org Subject: Re: The python black project.
On 2019-04-23 15:39:48 +0100 (+0100), Sean Mooney wrote: [...]
ya i think i could get more behind autopep8 or yapf. running autopep8 on nova https://review.opendev.org/#/c/655171/ has very little change
litrally adding 1 empty new line to to 102 files that with almost 0 other code curn. using autopep8 however would fix any actul pep8 issue in new patches automatically without the downsides of black.
[...]
I'm more concerned with the implementation logistics, honestly. How do you propose going about this? If you want to use a Git commit or pre-commit hook then you can do it already--go for it. If you want everyone proposing changes to the same repository to use the same commit hook, that becomes a distribution/enforcement challenge to solve. If you want it somehow enforced on the receiving end of the push, say with a receive hook, that's brittle and will have side effects such as invalidating signed commits (which we're able to support at the moment).
Basically the only friendly and reliable way to enforce this centrally is to have the desired style conventions validated upon receipt by the code review system and the results reported back to the committer. This is exactly what we already do today. There are of course also ways to reject the change with a push error so that the committer has to amend and push again, but that's not easy to manage across different projects and also doesn't solve your desire to "not need to think about code style" (paraphrased).
There is also the possibility that you simply run a periodic autopep8 job against the codebase and have that job propose a commit to the repository to apply code style changes if there are any, but that's a bit of a messy hack as well. -- Jeremy Stanley
On 2019-04-23 20:22:04 +0100 (+0100), Sean Mooney wrote:
On Tue, 2019-04-23 at 19:06 +0000, Fox, Kevin M wrote:
If you want to use a Git commit or pre-commit hook then you can do it already--go for it. If you want everyone proposing changes to the same repository to use the same commit hook, that becomes a distribution/enforcement challenge to solve. [...] I've wondered for a while if you could automate the automation. So, like, run the autoformatter and feed back the generated
On Tue, 2019-04-23 at 15:39 +0000, Jeremy Stanley wrote: [...] patch back to the developer in a way they can easily accept it. Like, making a pr against their pr with the formatting fixes, so that they can easily merge it in.
well you can with a pre-commit hook + a job chagne to enforce it. so pre-commit hook runs an autopep8 tox env. if the tox run modifies any files fail the commit. in the gate we also assert the same thing in the pep8 job. and retrun the diff in the logs somewhere [...]
That's basically exactly what I said up-thread... there's nothing stopping you from setting your environment up to run your diff through autopep8 before committing, for example via a local Git hook. If you want others to do the same, you need to solve the hook distribution and installation problem. We already refuse to merge changes which fail our pep8 CI jobs, so that's effectively the same as running autopep8 in a job and returning a diff in the logs (but harder to do things like start taking advantage of Zuul's recently-added ability to leave inline review comments, since you'd no longer have the line-oriented reports flake8 gives you, though I guess the same job could *also* run autopep8, it's not like it would add much to the job duration). -- Jeremy Stanley
Thats a slightly different thing, as it modifies the user contribution on the way in. That arguably breaks signoffs and the like, as well as git history for someone pushing vs pulling I think? Feeding back the patchs though so the user doesn't have to write them, but easly can accept them I think is a better middle ground? It automates the time consuming parts, but goes through the workflow in such a way as not to break other things? Thanks, Kevin ________________________________________ From: Sean Mooney [smooney@redhat.com] Sent: Tuesday, April 23, 2019 12:22 PM To: Fox, Kevin M; Jeremy Stanley; openstack-discuss@lists.openstack.org Subject: Re: The python black project. On Tue, 2019-04-23 at 19:06 +0000, Fox, Kevin M wrote:
I've wondered for a while if you could automate the automation. So, like, run the autoformatter and feed back the generated patch back to the developer in a way they can easily accept it. Like, making a pr against their pr with the formatting fixes, so that they can easily merge it in. well you can with a pre-commit hook + a job chagne to enforce it. so pre-commit hook runs an autopep8 tox env. if the tox run modifies any files fail the commit. in the gate we also assert the same thing in the pep8 job. and retrun the diff in the logs somewhere
anyway i know not everyone would be on board with that but its what i would proably do if i was starting proejct from scratch.
Thanks, Kevin ________________________________________ From: Jeremy Stanley [fungi@yuggoth.org] Sent: Tuesday, April 23, 2019 11:39 AM To: openstack-discuss@lists.openstack.org Subject: Re: The python black project.
On 2019-04-23 15:39:48 +0100 (+0100), Sean Mooney wrote: [...]
ya i think i could get more behind autopep8 or yapf. running autopep8 on nova https://review.opendev.org/#/c/655171/ has very little change
litrally adding 1 empty new line to to 102 files that with almost 0 other code curn. using autopep8 however would fix any actul pep8 issue in new patches automatically without the downsides of black.
[...]
I'm more concerned with the implementation logistics, honestly. How do you propose going about this? If you want to use a Git commit or pre-commit hook then you can do it already--go for it. If you want everyone proposing changes to the same repository to use the same commit hook, that becomes a distribution/enforcement challenge to solve. If you want it somehow enforced on the receiving end of the push, say with a receive hook, that's brittle and will have side effects such as invalidating signed commits (which we're able to support at the moment).
Basically the only friendly and reliable way to enforce this centrally is to have the desired style conventions validated upon receipt by the code review system and the results reported back to the committer. This is exactly what we already do today. There are of course also ways to reject the change with a push error so that the committer has to amend and push again, but that's not easy to manage across different projects and also doesn't solve your desire to "not need to think about code style" (paraphrased).
There is also the possibility that you simply run a periodic autopep8 job against the codebase and have that job propose a commit to the repository to apply code style changes if there are any, but that's a bit of a messy hack as well. -- Jeremy Stanley
On Tue, 2019-04-23 at 19:56 +0000, Fox, Kevin M wrote:
Thats a slightly different thing, as it modifies the user contribution on the way in. That arguably breaks signoffs and the like, as well as git history for someone pushing vs pulling I think?
Feeding back the patchs though so the user doesn't have to write them, but easly can accept them I think is a better middle ground? It automates the time consuming parts, but goes through the workflow in such a way as not to break other things? well what i was thinking was we would use the return code of autopep8 as the job sucess
--exit-code change to behavior of exit code. default behavior of return value, 0 is no differences, 1 is error exit. return 2 when add this option. 2 is exists differences. so in the gate we coudl invoke "tox -e autopep8 -- --diff > result.diff" and just use the execode to know if it woudl change somehting. if it exeits 0 then the job passes if it exits 1 then it fails and the the user can grab the diff an apply it or they coudl just run "tox -e autopep8 -- --in-place" then in either case the locally git add and git commit --amend and resubmit to make sure authership is preserved. the autopep8 tox enve could also automate runing it on only the files changed in the current commit to minimise chrun like the fast8 env does. that would allow use to fix things incrementlaly as we go. i might just code this up but i dont really want to waste time on it if it will never merge.
Thanks, Kevin ________________________________________ From: Sean Mooney [smooney@redhat.com] Sent: Tuesday, April 23, 2019 12:22 PM To: Fox, Kevin M; Jeremy Stanley; openstack-discuss@lists.openstack.org Subject: Re: The python black project.
On Tue, 2019-04-23 at 19:06 +0000, Fox, Kevin M wrote:
I've wondered for a while if you could automate the automation. So, like, run the autoformatter and feed back the generated patch back to the developer in a way they can easily accept it. Like, making a pr against their pr with the formatting fixes, so that they can easily merge it in.
well you can with a pre-commit hook + a job chagne to enforce it. so pre-commit hook runs an autopep8 tox env. if the tox run modifies any files fail the commit. in the gate we also assert the same thing in the pep8 job. and retrun the diff in the logs somewhere
anyway i know not everyone would be on board with that but its what i would proably do if i was starting proejct from scratch.
Thanks, Kevin ________________________________________ From: Jeremy Stanley [fungi@yuggoth.org] Sent: Tuesday, April 23, 2019 11:39 AM To: openstack-discuss@lists.openstack.org Subject: Re: The python black project.
On 2019-04-23 15:39:48 +0100 (+0100), Sean Mooney wrote: [...]
ya i think i could get more behind autopep8 or yapf. running autopep8 on nova https://review.opendev.org/#/c/655171/ has very little change
litrally adding 1 empty new line to to 102 files that with almost 0 other code curn. using autopep8 however would fix any actul pep8 issue in new patches automatically without the downsides of black.
[...]
I'm more concerned with the implementation logistics, honestly. How do you propose going about this? If you want to use a Git commit or pre-commit hook then you can do it already--go for it. If you want everyone proposing changes to the same repository to use the same commit hook, that becomes a distribution/enforcement challenge to solve. If you want it somehow enforced on the receiving end of the push, say with a receive hook, that's brittle and will have side effects such as invalidating signed commits (which we're able to support at the moment).
Basically the only friendly and reliable way to enforce this centrally is to have the desired style conventions validated upon receipt by the code review system and the results reported back to the committer. This is exactly what we already do today. There are of course also ways to reject the change with a push error so that the committer has to amend and push again, but that's not easy to manage across different projects and also doesn't solve your desire to "not need to think about code style" (paraphrased).
There is also the possibility that you simply run a periodic autopep8 job against the codebase and have that job propose a commit to the repository to apply code style changes if there are any, but that's a bit of a messy hack as well. -- Jeremy Stanley
Are you still thinking precommit hook there? I usually prefer server side hooks as then I don't have to deploy all the developer tools all of the random repos I contribute to require all the time. If it can be made server side somehow, thats vastly easier to deal with by folks like me or other drive by contributors. I'm thinking more along the line of, we have a bunch of gate blocking tests that ensure some amount of code quality going in. But what if we could take it to the next level and have those tests actually feed back quality enhancements too, not just saying no and without the developer to install extra tools? Thanks, Kevin ________________________________________ From: Sean Mooney [smooney@redhat.com] Sent: Tuesday, April 23, 2019 1:13 PM To: Fox, Kevin M; Jeremy Stanley; openstack-discuss@lists.openstack.org Subject: Re: The python black project. On Tue, 2019-04-23 at 19:56 +0000, Fox, Kevin M wrote:
Thats a slightly different thing, as it modifies the user contribution on the way in. That arguably breaks signoffs and the like, as well as git history for someone pushing vs pulling I think?
Feeding back the patchs though so the user doesn't have to write them, but easly can accept them I think is a better middle ground? It automates the time consuming parts, but goes through the workflow in such a way as not to break other things? well what i was thinking was we would use the return code of autopep8 as the job sucess
--exit-code change to behavior of exit code. default behavior of return value, 0 is no differences, 1 is error exit. return 2 when add this option. 2 is exists differences. so in the gate we coudl invoke "tox -e autopep8 -- --diff > result.diff" and just use the execode to know if it woudl change somehting. if it exeits 0 then the job passes if it exits 1 then it fails and the the user can grab the diff an apply it or they coudl just run "tox -e autopep8 -- --in-place" then in either case the locally git add and git commit --amend and resubmit to make sure authership is preserved. the autopep8 tox enve could also automate runing it on only the files changed in the current commit to minimise chrun like the fast8 env does. that would allow use to fix things incrementlaly as we go. i might just code this up but i dont really want to waste time on it if it will never merge.
Thanks, Kevin ________________________________________ From: Sean Mooney [smooney@redhat.com] Sent: Tuesday, April 23, 2019 12:22 PM To: Fox, Kevin M; Jeremy Stanley; openstack-discuss@lists.openstack.org Subject: Re: The python black project.
On Tue, 2019-04-23 at 19:06 +0000, Fox, Kevin M wrote:
I've wondered for a while if you could automate the automation. So, like, run the autoformatter and feed back the generated patch back to the developer in a way they can easily accept it. Like, making a pr against their pr with the formatting fixes, so that they can easily merge it in.
well you can with a pre-commit hook + a job chagne to enforce it. so pre-commit hook runs an autopep8 tox env. if the tox run modifies any files fail the commit. in the gate we also assert the same thing in the pep8 job. and retrun the diff in the logs somewhere
anyway i know not everyone would be on board with that but its what i would proably do if i was starting proejct from scratch.
Thanks, Kevin ________________________________________ From: Jeremy Stanley [fungi@yuggoth.org] Sent: Tuesday, April 23, 2019 11:39 AM To: openstack-discuss@lists.openstack.org Subject: Re: The python black project.
On 2019-04-23 15:39:48 +0100 (+0100), Sean Mooney wrote: [...]
ya i think i could get more behind autopep8 or yapf. running autopep8 on nova https://review.opendev.org/#/c/655171/ has very little change
litrally adding 1 empty new line to to 102 files that with almost 0 other code curn. using autopep8 however would fix any actul pep8 issue in new patches automatically without the downsides of black.
[...]
I'm more concerned with the implementation logistics, honestly. How do you propose going about this? If you want to use a Git commit or pre-commit hook then you can do it already--go for it. If you want everyone proposing changes to the same repository to use the same commit hook, that becomes a distribution/enforcement challenge to solve. If you want it somehow enforced on the receiving end of the push, say with a receive hook, that's brittle and will have side effects such as invalidating signed commits (which we're able to support at the moment).
Basically the only friendly and reliable way to enforce this centrally is to have the desired style conventions validated upon receipt by the code review system and the results reported back to the committer. This is exactly what we already do today. There are of course also ways to reject the change with a push error so that the committer has to amend and push again, but that's not easy to manage across different projects and also doesn't solve your desire to "not need to think about code style" (paraphrased).
There is also the possibility that you simply run a periodic autopep8 job against the codebase and have that job propose a commit to the repository to apply code style changes if there are any, but that's a bit of a messy hack as well. -- Jeremy Stanley
On 2019-04-23 20:26:10 +0000 (+0000), Fox, Kevin M wrote: [...]
I usually prefer server side hooks as then I don't have to deploy all the developer tools all of the random repos I contribute to require all the time. If it can be made server side somehow, thats vastly easier to deal with by folks like me or other drive by contributors.
Server-side hooks are fine for rejecting a push (if somewhat inflexible and hard to manage across projects, and in most ways inferior to equivalent CI jobs), but you don't want them altering commits as that invalidates any commit signing (in the git commit -S/--gpg-sign sense, not the -s/--signoff sense) the original committer may have performed.
I'm thinking more along the line of, we have a bunch of gate blocking tests that ensure some amount of code quality going in. But what if we could take it to the next level and have those tests actually feed back quality enhancements too, not just saying no and without the developer to install extra tools? [...]
The suggestion to have automation push a revision to a patch you propose while it's still under review is an interesting one, though it does bear some resemblance to the server-side hooks problem. The commit which would be approved and merged at that point isn't identified as yours. Some attempt could be made to have the automation masquerade as your identity insofar as forging the committer details to match the prior patch, but it wouldn't be able to reproduce your cryptographic signature so *if* you're keen on OpenPGP-signing your commits, you'll lose that when the auto-revised version ends up merging instead of your original. -- Jeremy Stanley
Yeah, pushing a patch following the patch going in for review is more what I was thinking. So, a patch that fixes the previous patch, not actually rewriting the patch. Is it a problem for the commit to "come from" and be "signed off" by the automation itself? It surfaces the cleanup patches as just cleanup patches. And in the very end of the ps, we squash the pr on merge anyway? If the user wants, they can also just flatten the PS themselves and it would automatically merge in the automation provided patches. Thanks, Kevin ________________________________________ From: Jeremy Stanley [fungi@yuggoth.org] Sent: Tuesday, April 23, 2019 1:49 PM To: openstack-discuss@lists.openstack.org Subject: Re: The python black project. On 2019-04-23 20:26:10 +0000 (+0000), Fox, Kevin M wrote: [...]
I usually prefer server side hooks as then I don't have to deploy all the developer tools all of the random repos I contribute to require all the time. If it can be made server side somehow, thats vastly easier to deal with by folks like me or other drive by contributors.
Server-side hooks are fine for rejecting a push (if somewhat inflexible and hard to manage across projects, and in most ways inferior to equivalent CI jobs), but you don't want them altering commits as that invalidates any commit signing (in the git commit -S/--gpg-sign sense, not the -s/--signoff sense) the original committer may have performed.
I'm thinking more along the line of, we have a bunch of gate blocking tests that ensure some amount of code quality going in. But what if we could take it to the next level and have those tests actually feed back quality enhancements too, not just saying no and without the developer to install extra tools? [...]
The suggestion to have automation push a revision to a patch you propose while it's still under review is an interesting one, though it does bear some resemblance to the server-side hooks problem. The commit which would be approved and merged at that point isn't identified as yours. Some attempt could be made to have the automation masquerade as your identity insofar as forging the committer details to match the prior patch, but it wouldn't be able to reproduce your cryptographic signature so *if* you're keen on OpenPGP-signing your commits, you'll lose that when the auto-revised version ends up merging instead of your original. -- Jeremy Stanley
On 2019-04-23 21:09:30 +0000 (+0000), Fox, Kevin M wrote:
Yeah, pushing a patch following the patch going in for review is more what I was thinking. So, a patch that fixes the previous patch, not actually rewriting the patch.
Sure, that's essentially another of the options I mentioned in an earlier message:
There is also the possibility that you simply run a periodic autopep8 job against the codebase and have that job propose a commit to the repository to apply code style changes if there are any, but that's a bit of a messy hack as well.
The main reasons I consider it a "messy hack" is that it runs the potential of increasing the number of commits in the repository significantly depending on whether and how often you batch up the autofixes, and makes it harder to `git blame` effectively since a lot of changes are immediately followed by changes to those same lines by a generic automation account. It also means we give up on whatever benefits we might hope to gain from having consistency of style in proposed changes, as folks can propose code in any old format they like without regard for readability and it only gets cleaned up and made readable after it's been reviewed and approved. This strikes me as a slippery slope towards "it's okay if your code has obvious errors, we can find and fix them after it's merged."
Is it a problem for the commit to "come from" and be "signed off" by the automation itself?
No, we have automation propose other sorts of changes already. From a legal standpoint nobody's ever complained that the machine hasn't agreed to the ICLA or acknowledged the DCO. I think once we're successful enough with artificial intelligence for our computers to start filing patent infringement claims against us for the work they've written, we can revisit that position. If we wanted to have our existing auto-proposed changes use `git commit --gpg-sign` I think that would be able to take advantage of much of the same automated signing infrastructure we already leverage for our Git tags and related release artifacts. That much seems to me like it could be a good idea, if someone wants to do the work to add it. It would in theory allow any observer to confirm that the patches which claim to have originated within our automation actually have.
It surfaces the cleanup patches as just cleanup patches. And in the very end of the ps, we squash the pr on merge anyway? If the user wants, they can also just flatten the PS themselves and it would automatically merge in the automation provided patches. [...]
Now it's starting to sound like you're suggesting auto-proposing follow-up changes to each user-proposed change while it's still under review. I think it's probably technically possible, though likely to ~double our overall change volume insofar as review and testing go (especially when folks inevitably ignore them and so they get rebased and updated every time the parent change is updated). And before you say "it's okay to skip running CI jobs on those" it's really not, since we're not likely to blindly trust autopep8 not to propose a subtly broken modification. -- Jeremy Stanley
From: Jeremy Stanley [fungi@yuggoth.org] Sent: Tuesday, April 23, 2019 2:45 PM To: openstack-discuss@lists.openstack.org Subject: Re: The python black project.
*SNIP*
Now it's starting to sound like you're suggesting auto-proposing follow-up changes to each user-proposed change while it's still under review.
That was what I was trying to explain and failing. That is what I am proposing. :)
I think it's probably technically possible, though l> ikely to ~double our overall change volume insofar as review and testing go (especially when folks inevitably ignore them and so they get rebased and updated every time the parent change is updated). And before you say "it's okay to skip running CI jobs on those" it's really not, since we're not likely to blindly trust autopep8 not to propose a subtly broken modification.
Yeah, I wouldn't recommend blindly trusting it either... it could short circuit all the other tests though, like: do the linting tests before any other tests. if it fails, end review of the whole PS and submit back a cleanup patch. Then start over with the testing. So test wise, it wouldn't be too expensive. But it could easily double the number of reviews like you point out, if that is an issue.
Jeremy Stanley
Thanks, Kevin
On Tue, 2019-04-23 at 18:39 +0000, Jeremy Stanley wrote:
On 2019-04-23 15:39:48 +0100 (+0100), Sean Mooney wrote: [...]
ya i think i could get more behind autopep8 or yapf. running autopep8 on nova https://review.opendev.org/#/c/655171/ has very little change
litrally adding 1 empty new line to to 102 files that with almost 0 other code curn. using autopep8 however would fix any actul pep8 issue in new patches automatically without the downsides of black.
[...]
I'm more concerned with the implementation logistics, honestly. How do you propose going about this? If you want to use a Git commit or pre-commit hook then you can do it already--go for it. i honestly have been a little reluctanet to do that in the past jsut because it might cause unrelated changes and peopel will nit pick them as such. If you want everyone proposing changes to the same repository to use the same commit hook, that becomes a distribution/enforcement challenge to solve. If you want it somehow enforced on the receiving end of the push, say with a receive hook, that's brittle and will have side effects such as invalidating signed commits (which we're able to support at the moment).
Basically the only friendly and reliable way to enforce this centrally is to have the desired style conventions validated upon receipt by the code review system and the results reported back to the committer. This is exactly what we already do today. There are of course also ways to reject the change with a push error so that the committer has to amend and push again, but that's not easy to manage across different projects and also doesn't solve your desire to "not need to think about code style" (paraphrased). well looking at autopep8 again its much less invasive then i had assumed it would be so i might start using it locally personally.
There is also the possibility that you simply run a periodic autopep8 job against the codebase and have that job propose a commit to the repository to apply code style changes if there are any, but that's a bit of a messy hack as well. honestly i was thinking if we went with autopep8 we just add it to the pep8 tox env. so you run pep8 locally/in the gate and it fixes everythign it can and if there are any failure you can jsut fix them youself.
the fact that auto pep8 seams to be really concervitve and only fix pep8 issues which flake8 would not allow anyway is a saving grace as it mean there will be very litte code churn. also autopep8 is the default formater for python in vscode and other ids support it too so for those that use them its pretty trivial to use by pressing ctrl+shift+i to format the current file. that said it dose not help me when im using nano/emacs but i run tox -e pep8 anyway before i push. if that auto fixed pep8 issue too when it could that would be nice. one thing that i think is important however is that the authorship of the change not be effected so in the gate if autopep8 would casuse a code chagne i would want the job to fail. maybe haveign the two be seperate woudl actully be better e.g. have an autopep8 tox env jsut for running it. im honestly getting burt out by this topic but i thin this could be a nice middle ground. that or stay as we are but my inital exciment over maybe useing black has been extinguished by actully using it and this thread.
I had my concerns when I saw Python Black promoted in other quite some time ago, and the same concern strikes me now I revisited it. I strongly oppose Python Black adoption for this reason: https://black.readthedocs.io/en/stable/the_black_code_style.html#line-length 88 char line lengths is a table stakes deal breaker for me (and I suspect others), and since the black project relies on no exceptions or discussions about details, this makes it a non-starter. -1 for me. David. On Thu, Apr 18, 2019 at 4:52 AM Natal Ngétal <natal@redhat.com> 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.
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.
My best regards
On Thu, 2019-04-18 at 16:42 -0400, David Peacock wrote:
I had my concerns when I saw Python Black promoted in other quite some time ago, and the same concern strikes me now I revisited it.
I strongly oppose Python Black adoption for this reason:
https://black.readthedocs.io/en/stable/the_black_code_style.html#line-length
88 char line lengths is a table stakes deal breaker for me (and I suspect others), and since the black project relies on no exceptions or discussions about details, this makes it a non-starter.
-1 for me. so i have mentioned this in the thread before but you can change there default
if you drop a pyproject.toml file into the root of the repo black will read its defaults from there so we can set something like the following [tool.black] line-length = 79 target_version = ['py27'] skip-string-normalization = true include = '\.pyi?$' exclude = ''' ( /( \.eggs # exclude a few common directories in the | \.git # root of the project | \.tox | \.venv | \docs | \releasenotes )/ ) ''' that will disable the "" to '' normalisation and it will keep the line-length at 79 yapf is more configurable but black allows you to set the 2 things that most people take issue with. the line lenght and stings.
David. On Thu, Apr 18, 2019 at 4:52 AM Natal Ngétal <natal@redhat.com> 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. 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. My best regards
On Thu, Apr 18, 2019 at 10:42 PM David Peacock <dpeacock@redhat.com> wrote:
I had my concerns when I saw Python Black promoted in other quite some time ago, and the same concern strikes me now I revisited it.
I strongly oppose Python Black adoption for this reason:
https://black.readthedocs.io/en/stable/the_black_code_style.html#line-length
88 char line lengths is a table stakes deal breaker for me (and I suspect others), and since the black project relies on no exceptions or discussions about details, this makes it a non-starter.
Sorry but for me is not a good argument. This default behaviour can be change easily. I also prefer 79 character per line, pep8 change, but I still to continue to prefer 79 character per line. However I can use black for my project, because I can change this behaviour.
On Apr 19, 2019, at 5:34 AM, Natal Ngétal <natal@redhat.com> wrote:
88 char line lengths is a table stakes deal breaker for me (and I suspect others), and since the black project relies on no exceptions or discussions about details, this makes it a non-starter. Sorry but for me is not a good argument. This default behaviour can be change easily. I also prefer 79 character per line, pep8 change, but I still to continue to prefer 79 character per line. However I can use black for my project, because I can change this behaviour.
Black is a strongly opinionated tool. You either buy into its opinions or you don’t. If you start out assuming that you are going to diverge from the author’s opinions, you really shouldn’t be using the tool. -- Ed Leafe
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. -- Thanks, Matt
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
On Fri, 2019-04-19 at 08:35 -0500, Matt Riedemann wrote: 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.
participants (21)
-
Chris Dent
-
Clark Boylan
-
Clint Byrum
-
David Peacock
-
Dmitry Tantsur
-
Ed Leafe
-
Fox, Kevin M
-
Ivan Kolodyazhny
-
Jeremy Stanley
-
Lance Bragstad
-
Mats Bollo
-
Matt Riedemann
-
Michael McCune
-
Monty Taylor
-
Morgan Fainberg
-
Natal Ngétal
-
Sean McGinnis
-
Sean Mooney
-
Slawomir Kaplonski
-
Sorin Sbarnea
-
Stephen Finucane