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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Black Formatting #464
Add Black Formatting #464
Conversation
i don't know if this pr will be accepted, but maybe add pre commit black or use darker https://github.com/akaihola/darker |
Yes, pre-commit black would be the best option馃憤
Not every PR/push is made on the desktop, which is why I included the workflow.
I'm 100% sure some commits would slip by unformatted if the workflow was removed,
The Autoblack workflow has a really neat feature to automatically edit PR's or create PR's if any push does not pass Black's check
I'd personally set it to do a daily run over the repo and run on every new PR, but that's just my opinion, so I left it as it was set in Autoblack's source
|
If Theo wishes for the repo to have style guidelines, it'll be best to get them done sooner rather than later -- Merging already existing PRs after a large restyling like this could be a bit annoying, best to do it when there
are few open PRs馃憤
If not, I'd get it removed from the pre-PR checklist 馃槀
|
i think only #424 change the main program other than that other pr mainly for non python file |
I have literally no idea what this means |
It's about consistency across the codebase --
Some decent resources on the topic are:
https://searchbusinessanalytics.techtarget.com/tip/Python-code-formatting-Tools-you-need-and-why-it-matters
https://youtu.be/j1MbEYhYj_Y
And
https://www.python.org/dev/peps/pep-0008/
A great quote from the Python's PEP 8 is
"One of Guido's key insights is that code is read much more often than it is written"
Best to keep the codebase readable馃憤
|
simpler explanation
is it too much @ThioJoe? if yes, maybe reduce the pr to essential and let thiojoe reformat the codebase |
The majority of the commit is changing single quotes to double quotes (and As a note to Thio: none of this changes any of the existing code, it only changes the way it looks [...]
- text =post['contentText']['runs'][0]['text'].strip().replace('\n','').replace('\r', '')
+ text = (
+ post["contentText"]["runs"][0]["text"]
+ .strip()
+ .replace("\n", "")
+ .replace("\r", "")
+ )
[...] (Deleted original to fix markdown) |
@ThioJoe Also, if you are unaware of what a pre-commit is, I'd recommend checking out https://githooks.com/ The .git/hooks/pre-commit file tells git what to run before commiting files,
to the file should work馃憤 |
Example run of black-push workflow (with the "auto fix" feature commented out) |
Adding pre-commit would also benefit this project. |
Yes, I use the desktop app sometimes, but I mostly use the web application to commit/make PR's |
Working on it right now 馃憤 |
It's formatting which is objective so that everyone has to agree on following the same convention, that's what Black is, a forceful formatter that is pretty standard across python scripts. It has no effect on code functionality and is purely "cosmetic" in the sense that it's just so that everything follows formatting conventions. |
Oops -- Workflow made that |
This reverts commit 6a40730.
@ThioJoe The changes should be ready for review -- The workflow (example run) will automatically style & format the codebase after you merge this PR (if you do), so I recommend merging any other PRs you want before merging in this one.
|
Changes reverted in Revert "Fix formatting issues with long dictionary names" can be re-added in a separate pull request should this be accepted 馃憤 |
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.
CONTRIBUTING.md should get a complete update, but I think adding a note about Black should be enough for this PR
if you use pre commit, you may don't need to think about it because every commit will be autoformatted maybe some note on how to setup your fork on contributing.md, example below set up your fork
e: for poetry with pyproject set up your fork
|
Not everyone commits from desktop:
Yeah for sure 馃憤 |
i have read it unfortunately the pr change too much but it is mostly correct
i hope @dekoza can split the pr so better contributing.md can be used |
@rachmadaniHaryono I did what I could to minimize the changes. I used copier-poetry to create the basic directory structure and then moved most of the files into proper places. Then I refactored imports so that everything should work. Right now - since there are no tests - I'm trying to check if everything still works fine. If you ignore those several files added by |
Fetch upstream to ensure no merge conflicts ^^ |
dekoza close 489, maybe you can copy pretty-format-yaml hook to make sure all yaml file have the same format |
Taken from #489
I updated .pre-commit-config.yaml to match #489 Maybe pyproject, but that seems more of a poetry thing |
Also, the failed check can be ignored, obviously, the current state of the repo would not pass a Black formatting check 馃榿 |
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.
also run pre commit autoupdate to make sure it use latest version
as far as i can tell only some hook pre commit |
Doing this right now As for the other issues you mentioned, I'll just comment out those parts of the yaml file for later 馃憤 |
Tbh I don't really have any intention of adding this, I don't really understand the benefit |
Another brick in the wall... |
Dude chill out, its not your repo. If you don't like a choice you don't have to deal with it lol |
Who was this comment directed to @Masamune3210 |
|
Ok lol, I think he was just joking though. |
Changes
This change is entirely a style change -- There will be no impact on the code's performance from this
requirements.txt does not need to be updated -- this is not a requirement for running the code
Fixes
Checklist: