> My concerns are: > - The product is clearly marked as beta with a big warning. > - It looks like mostly a single person project. For the same reason I also > strongly prefer not using a fork for a specific setting. Fork will only have > less people looking at it.
I suppose the project is marked as beta because it is recent, it was presented in 2018’s pycon, and because some things can change since auto-formatters are pretty tricky beasts, I think beta in that case is like our own ‘@Experimental’. If you look at the contribution page [1] you can notice that it is less and less a single person project, there have been 93 independent contributions since the project became public, and the fact that it is hosted in the python organization github [2] gives some confidence on the project continuity. You are right however about the fact that the main author seems to be the ‘benevolent’ dictator, and in the 2-spaces issue he can seem arbitrary, but he is just following pep8 style guide recommendations [3]. I am curious of why we (Beam) do not follow the 4 spaces recommendation of PEP-8 or even Google's own Python style guide [4], So, probably it should be to us to reconsider the current policy to adapt to the standards (and the tool). I did a quick run of black with python 2.7 compatibility on sdks/python and got only 4 parsing errors which is positive given the size of our code base. 415 files reformatted, 45 files left unchanged, 4 files failed to reformat. error: cannot format /home/ismael/upstream/beam/sdks/python/apache_beam/runners/interactive/display/display_manager.py: Cannot parse: 47:22: _display_progress = print error: cannot format /home/ismael/upstream/beam/sdks/python/apache_beam/runners/worker/log_handler.py: Cannot parse: 151:18: file=sys.stderr) error: cannot format /home/ismael/upstream/beam/sdks/python/apache_beam/runners/worker/sdk_worker.py: Cannot parse: 160:34: print(traceback_string, file=sys.stderr) error: cannot format /home/ismael/upstream/beam/sdks/python/apache_beam/typehints/trivial_inference.py: Cannot parse: 335:51: print('-->' if pc == last_pc else ' ', end=' ') I still think this can be positive for the project but well I am barely a contributor to the python code base so I let you the python maintainers to reconsider this, in any case it seems like a good improvement for the project. [1] https://github.com/python/black/graphs/contributors [2] https://github.com/python [3] https://www.python.org/dev/peps/pep-0008/#indentation [4] https://github.com/google/styleguide/blob/gh-pages/pyguide.md#34-indentation On Tue, May 28, 2019 at 11:15 PM Ahmet Altay <al...@google.com> wrote: > > I am in the same boat with Robert, I am in favor of autoformatters but I am > not familiar with this one. My concerns are: > - The product is clearly marked as beta with a big warning. > - It looks like mostly a single person project. For the same reason I also > strongly prefer not using a fork for a specific setting. Fork will only have > less people looking at it. > > IMO, this is in an early stage for us. That said lint issues are real as > pointed in the thread. If someone would like to give it a try and see how it > would look like for us that would be interesting. > > On Tue, May 28, 2019 at 4:44 AM Katarzyna Kucharczyk > <ka.kucharc...@gmail.com> wrote: >> >> This sounds really good. A lot of Jenkins jobs failures are caused by lint >> problems. >> I think it would be great to have something similar to Spotless in Java SDK >> (I heard there is problem with configuring Black with IntelliJ). >> >> On Mon, May 27, 2019 at 10:52 PM Robert Bradshaw <rober...@google.com> wrote: >>> >>> I'm generally in favor of autoformatters, though I haven't looked at >>> how well this particular one works. We might have to go with >>> https://github.com/desbma/black-2spaces given >>> https://github.com/python/black/issues/378 . >>> >>> On Mon, May 27, 2019 at 10:43 PM Pablo Estrada <pabl...@google.com> wrote: >>> > >>> > This looks pretty good:) I know at least a couple people (myself >>> > included) who've been annoyed by having to take care of lint issues that >>> > maybe a code formatter could save us. >>> > Thanks for sharing Ismael. >>> > -P. >>> > >>> > >>> > On Mon, May 27, 2019, 12:24 PM Ismaël Mejía <ieme...@gmail.com> wrote: >>> >> >>> >> I stumbled by chance into Black [1] a python code auto formatter that >>> >> is becoming the 'de-facto' auto-formatter for python, and wanted to >>> >> bring to the ML Is there interest from the python people to get this >>> >> into the build? >>> >> >>> >> The introduction of spotless for Java has been a good improvement and >>> >> maybe the python code base may benefit of this too. >>> >> >>> >> WDYT? >>> >> >>> >> [1] https://github.com/python/black