-
Notifications
You must be signed in to change notification settings - Fork 77
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CI: switch formatter to black. #763
Conversation
xdsl/rewriting/composable_rewriting/immutable_ir/immutable_ir.py
Outdated
Show resolved
Hide resolved
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #763 +/- ##
==========================================
- Coverage 87.01% 87.00% -0.01%
==========================================
Files 110 110
Lines 16160 16161 +1
Branches 2405 2405
==========================================
Hits 14061 14061
- Misses 1650 1651 +1
Partials 449 449
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report in Codecov by Sentry. |
c38f4f2
to
21e8292
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that's fine for me!
I just think we shouldn't make the switch "just" because yapf doesn't support match
, because it will very soon (google/yapf#1067).
However, black
seems to add some changes that are nice:
- It will add a line to the end of a file if not added
- It adds parentheses in import automatically
- It makes the code consistent in multiple ways (for instance, using
'
rather than"
But, we lose - Conciceness, because now things get a bit longer
So to me, we should rather make our decisions with these points, rather than the match
issue that might be resolved soon.
I'm still in favor of black, that being said.
And I don't think we should make it a multi-stage process, let's just merge all at once, it's only formatting, so we can always format before rebase to make this easy.
By the way, to make the process smoother, how easy would it be to have a github bot that can format the code with a single command?
@@ -1,4 +1,4 @@ | |||
yapf<0.34 | |||
black |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we add a version here?
tests/dialects/test_memref.py
Outdated
builtin.f64, [-1, -1] | ||
) | ||
|
||
module = builtin.ModuleOp.from_region_or_ops( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We probably want to black disable here, otherwise the code is horrible :/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mh, I guess you are bothered by the arguments on a line each, right? Reading your comment I expected worse to be honest. This is a bit too much, but spaced and readable I'd say!
I'll see if there's some trailing coma thing to do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apparently no, but hey, may I note that it was yapf-disabled already? For the black vs yapf decision; adding some black ignore there.
Black has block ignoring by the way, which might be a nice way to have our formatting free for these implicit builders code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am personally fine with this. IMO, the code looks bad, but it still readable/understandable, which is more important to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Keep in mind that for non-horrible code, I'd recommend using builders instead
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can file a GitHub issue on me to migrate it if you want
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you check black formatting on builder code and stand by it? Open question, I didn't check it yet
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Keep in mind that for non-horrible code, I'd recommend using builders instead
We can try, but not sure that this will solve it.
The problem here is that there are many identations, so it makes the code worse and worse.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you check black formatting on builder code and stand by it? Open question, I didn't check it yet
Yep, it's unchanged from yapf
Good point for the issue. I'm not very confident in yapf supporting it soon from reading it though, but what do I know! I'm happy to wait it out a bit, and hope that match is the only issue if this PR face resistance then. But I don't think we should block |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❤️
I personally don't care all that much. Changing my environment setup is a bit of a pain, but usually it works quite well in the end. Now the match thing is an issue, but should be fixed soon. That's all nice and good until you realise: (1) it has been 1.5 years (!) since the release of python 3.10. From quick googling, it seems that black on the other hand needed 1.5 months until they had experimental support for match. Obviously, this does not matter anymore as soon as yapf supports match. But what about the next language feature? IMO, 1.5 years comes close to a tool not being maintained. I guess yapf is just a google thing and they won't care until enough google people care. Therefore, I am also in favor of the switch. |
I share this thought! Now @math-fehr had some legit comments on some formatting in places, I'll see if I find quick ways to make those better, but otherwise I'm in favour of the switch, living with it and seeing if it's all so bad in practice. Worst case scenario, we can always switch back and ignore the format back commit too |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this better?
It allows us to use structural pattern matching, which makes yapf crash. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀 🚀🚀
I prefer Black's choices tbh, and I like that it's not configurable. I generally feel that formatting is not as important as consistency, and Black seems to do it better, and is 5x faster than yapf, if I understand correctly. I notice the formatting lag on my machine and would love to live in a world without lag :) |
Nice! So I would only like to go over things that were yapf ignored before, and black ignore them and keep their precedent styling. |
08bb7ab
to
b9b1d60
Compare
b9b1d60
to
c1050be
Compare
Probably worth announcing on Zulip |
I also see that there are still references to |
This monster PR is switching the whole codebase to black formating.
Important motivation reminder: black handles
match
, yapf does not.I think it's very frustrating to prevent a whole language feature usage for tooling reasons (or even styling reasons, if the discussion steers there), where we have an alternative.
This PR takes care of setting the commit that just switch the format to be ignored in git blame, so we do not lose information there. The changes to the CI are not ignored, so future contributors will be able to blame me for this change 😉
If we want to be more progressive, I guess we can do it subfolder by subfolder? Not sure how painful that will be IDE wise though!