This is an archive of the discontinued LLVM Phabricator instance.

[NFC][Py Reformat] Reformat python files in mlir subdir
ClosedPublic

Authored by thieta on May 17 2023, 7:55 AM.

Details

Summary

This is an ongoing series of commits that are reformatting our
Python code.

Reformatting is done with black.

If you end up having problems merging this commit because you
have made changes to a python file, the best way to handle that
is to run git checkout --ours <yourfile> and then reformat it
with black.

If you run into any problems, post to discourse about it and
we will try to help.

RFC Thread below:

https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style

Diff Detail

Event Timeline

thieta created this revision.May 17 2023, 7:55 AM
Herald added a reviewer: rriddle. · View Herald Transcript
Herald added a reviewer: aartbik. · View Herald Transcript
Herald added a reviewer: ftynse. · View Herald Transcript
Herald added a reviewer: aartbik. · View Herald Transcript
Herald added a reviewer: ftynse. · View Herald Transcript
Herald added a reviewer: dcaballe. · View Herald Transcript
Herald added a project: Restricted Project. · View Herald Transcript
thieta requested review of this revision.May 17 2023, 7:55 AM
thieta updated this revision to Diff 523679.May 19 2023, 12:37 AM

Updated diff to include all the missing files.

Rebase

Reformatting is done with black.

Can you make it more clear by providing the exact invocation?

If you end up having problems merging this commit because you

have made changes to a python file, the best way to handle that
is to run git checkout --ours <yourfile> and then reformat it
with black.

ours and theirs are reversed in a rebase: anyone who has on-going work and rebase on main will lose their work with git checkout --ours when encountering a conflict during a rebase, wouldn't they?

(otherwise, fine with me, but @ftynse should probably approve this)

MLIR has been using YAPF with Google style for a while for Python code. Running that results in a relatively clean diff (https://reviews.llvm.org/D151112) compared to near-complete reformatting here. I wonder if it would be preferable to stick to the existing style here. If not, we should also remove the format files like this one: https://github.com/llvm/llvm-project/blob/main/mlir/python/.style.yapf. I'll post on discourse.

MLIR has been using YAPF with Google style for a while for Python code. Running that results in a relatively clean diff (https://reviews.llvm.org/D151112) compared to near-complete reformatting here. I wonder if it would be preferable to stick to the existing style here. If not, we should also remove the format files like this one: https://github.com/llvm/llvm-project/blob/main/mlir/python/.style.yapf. I'll post on discourse.

I am more concerned about divergence within the project than a one time diff here (it'll be easier to benefit from a pre-merge linter, have a unified doc and workflow for contributors, etc), and it is true that historically the LLVM project has been discouraging mass-fixes like this one, but MLIR has been more aggressive with this kind of mass clang-tidy / clang-format fixes as well.

Let's be more practical: looking at the diff, do you see regressions in readability / maintainability with the new format @ftynse ?
I see mostly neutral to positive changes.

There a things were neither the old nor the new one are optimal to me, but neither are obviously worse than the other, for example:

if (
    isinstance(attribute, types.FunctionType)
    and attribute_name.startswith(function_prefix)
):
    module_functions.append(attribute)

becomes:

if isinstance(attribute, types.FunctionType) and attribute_name.startswith(
    function_prefix
):
    module_functions.append(attribute)

I would likely prefer to split on the and somehow:

if (isinstance(attribute, types.FunctionType) and
    attribute_name.startswith(function_prefix)):
    module_functions.append(attribute)

Anyway, seems like the migration to black in LLVM is already pretty far, unless we find problems with it in the diff, I think we should just land this!

I am more concerned about divergence within the project than a one time diff here (it'll be easier to benefit from a pre-merge linter, have a unified doc and workflow for contributors, etc), and it is true that historically the LLVM project has been discouraging mass-fixes like this one, but MLIR has been more aggressive with this kind of mass clang-tidy / clang-format fixes as well.

I'm on the same page regarding long-term divergence here and personally not opposed to the change, just want to make everyone is aware of the change.

Let's be more practical: looking at the diff, do you see regressions in readability / maintainability with the new format @ftynse ?

I prefer two-space over four-space indentation given how bad Python is with line splitting, but this is nitpicking.

Can we land this now? It's the one outstanding diff for closing out this reformat.

Please do! Thanks for driving this through, and thanks for the patience.

This revision was not accepted when it landed; it landed in state Needs Review.May 25 2023, 11:05 PM
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.