I think the question is if it can be configured in a way to fit our
current linter's style. I don't think it is feasible to reformat the
entire Python SDK.
Reformatted lines don't allow quick access to the Git history. This
effect is still visible in the Java SDK. However, I have the feeling
that this might be less of a problem with Python because the linter has
more rules than Checkstyle had.
-Max
On 29.05.19 10:16, Ismaël Mejía wrote:
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
