I attempted to take some initiative with this relation chain: https://gem5-review.googlesource.com/c/public/gem5/+/47000/
In short, I applied Python Black with a line length of 79, then added a Python black check to our pre-submit (Kokoro) tests. This patchset raised a question as to what line length we really want for Python. Our official policy has been <=79 characters but Black defaults to 88 (The black developers argue this default produces a good trade off between file length and line length). This is a good chance to have this discussion, so the floor is open. Personally, I'm not massively opposed but a consistent 79 character limit across the project has worked for us thus far and I don't personally see much reason to change. Kind regards, Bobby -- Dr. Bobby R. Bruce Room 3050, Kemper Hall, UC Davis Davis, CA, 95616 web: https://www.bobbybruce.net On Thu, Mar 4, 2021 at 8:05 AM Giacomo Travaglini via gem5-dev < gem5-dev@gem5.org> wrote: > > > > -----Original Message----- > > From: Jason Lowe-Power <ja...@lowepower.com> > > Sent: 04 March 2021 15:27 > > To: gem5 Developer List <gem5-dev@gem5.org> > > Cc: Gabe Black <gabe.bl...@gmail.com>; Giacomo Travaglini > > <giacomo.travagl...@arm.com> > > Subject: Re: [gem5-dev] Re: RFC: run python Black on gem5 python code > > > > Hi all, > > > > > > Some responses inline below. The other thing I'll mention is that I > believe we > > can integrate it in a way where it's completely invisible to most > developers. > > You can edit a file with whatever style you want, then after you run > black it will > > be in the PEP8 style. From my experience, the only things that need to be > > manually changed are quoted strings that are more than 80 characters. > > > > I would be very careful about hiding this to the developers at the point > of automatically changing their code > without having them noticing it. > > I understand you want developers to commit without the hassle of > explicitly dealing with style errors. > On the other hand though we are already doing this for C++ so I don't see > a reason why we shouldn't do the same > for the python world. > > Other options could be to run the linter as a pre-push hook, or to run the > linter as part of our presubmit Jenkins script. > > > On Thu, Mar 4, 2021 at 6:49 AM Giacomo Travaglini via gem5-dev <gem5- > > d...@gem5.org <mailto:gem5-dev@gem5.org> > wrote: > > > > > > Hi Jason, > > > > This is great news. When you say it is not configurable, do you mean it > > is not possible to suppress warning/errors or do you > > mean it is not possible to come up with custom rules? > > > > > > > > There is a way to suppress changes by modifying the file with a comment > `# > > fmt: off`. You can also exclude files with a dotfile (like .gitignore). > > > > > > > > As I presume it's the first case, I am wondering if a different linter > > might provide such capabilities: > > > > https://books.agiliq.com/projects/essential-python- > > tools/en/latest/linters.html > > > > Is there a reason to prefer black over other linters? > > > > > > > > It's owned by the python software foundation, which makes it seem > "official". > > Though the real reason is that it's the first one I looked at and the > only one I > > investigated. > > I actually thought pycodestyle was the "official" linter (I am not sure if > the "official" word makes completely sense though) > > I was asking this because for example in pycodestyle (and prob other > linters as well) there are error codes > https://pycodestyle.pycqa.org/en/latest/intro.html#error-codes you could > use include or exclude lists of errors (to ignore specific types of > warnings). > > Kind regards > > Giacomo > > > > > > > > > Kind regards > > > > Giacomo > > > > > -----Original Message----- > > > From: Gabe Black via gem5-dev <gem5-dev@gem5.org > > <mailto:gem5-dev@gem5.org> > > > > Sent: 04 March 2021 03:59 > > > To: gem5 Developer List <gem5-dev@gem5.org <mailto:gem5- > > d...@gem5.org> > > > > Cc: Gabe Black <gabe.bl...@gmail.com > > <mailto:gabe.bl...@gmail.com> > > > > Subject: [gem5-dev] Re: RFC: run python Black on gem5 python code > > > > > > I'm a little worried about the no exceptions part of that, since we > > might have > > > some weird restrictions that we have to do weird things to work > > around, but I > > > can't really think of an example of that off hand. I'd want to look at > it > > to see > > > how much wiggle room there is in the style, since I think ironclad > > rules which > > > make no accommodation for occasional common sense are maybe > > more > > > trouble than they're worth. I'm not opposed to having at least some > > stated > > > standard for python though, and the "official" one seems like a > > pretty > > > reasonable choice. I guess it's fine with me, up until it causes me > > some sort of > > > problem :-) > > > > > > > > I actually think it's a feature not a bug. With an "uncompromising > Python code > > formatter" there can be no arguments in code review about the style. > > > > > > > > > > Maybe the right thing to do would be to give it a shot but not make > > it > > > compulsory until we have a feeling for how much trouble it is. > > > > > > > > > Gabe > > > > > > On Wed, Mar 3, 2021 at 11:24 AM Bobby Bruce via gem5-dev <gem5- > > > d...@gem5.org <mailto:d...@gem5.org> <mailto:gem5- > > d...@gem5.org <mailto:gem5-dev@gem5.org> > > wrote: > > > > > > > > > Sounds like a good idea to me. > > > --- > > > > > > Dr. Bobby R. Bruce > > > Room 2235, > > > Kemper Hall, UC Davis > > > Davis, > > > CA, 95616 > > > > > > > > > web: https://www.bobbybruce.net > > > > > > > > > > > > On Wed, Mar 3, 2021 at 10:11 AM Daniel Carvalho via gem5-dev > > > <gem5-dev@gem5.org <mailto:gem5-dev@gem5.org> > > <mailto:gem5-dev@gem5.org <mailto:gem5-dev@gem5.org> > > wrote: > > > > > > > > > +1 > > > > > > > > > Em quarta-feira, 3 de março de 2021 14:35:57 BRT, Jason > > > Lowe-Power via gem5-dev <gem5-dev@gem5.org <mailto:gem5- > > d...@gem5.org> <mailto:gem5- <mailto:gem5-> > > > d...@gem5.org <mailto:d...@gem5.org> > > escreveu: > > > > > > > > > Hi all, > > > > > > Right now, we don't have an official style guide for python. > > > Our style guide > > > > > (http://www.gem5.org/documentation/general_docs/development/coding_st > > > yle/) is very C++ focused. > > > > > > I would like to propose adopting a relatively strict PEP 8 style > > > guide: https://www.python.org/dev/peps/pep-0008. This is the > > "official" style > > > guide for python (as much as there is anything official). I say > > "relatively strict" > > > to mean that we will limit our exceptions *as much as possible*. > > > > > > To implement this, Andreas S. recently pointed me to the > > > "Black" package (https://pypi.org/project/black/) which automatically > > fixes > > > code style. I just tried it out with gem5art (patch coming soon) and > > found that > > > it works really well. The only downside is that it's not configurable > at > > all. > > > Adding special cases would be almost impossible. > > > > > > Concrete and specific proposal: > > > - Adopt PEP 8 as our official style guide > > > - Use black to reformat all python code in src/ > > > - Use black to reformat code in configs/ > > > - Use black to reformat other python code > > > > > > - Use black as part of our commit hook to make sure all future > > > python is formatted to PEP 8 > > > > > > Let me know what you think! > > > > > > Cheers, > > > Jason > > > > > > _______________________________________________ > > > gem5-dev mailing list -- gem5-dev@gem5.org <mailto:gem5- > > d...@gem5.org> <mailto:gem5- <mailto:gem5-> > > > d...@gem5.org <mailto:d...@gem5.org> > > > > To unsubscribe send an email to gem5-dev-le...@gem5.org > > <mailto:gem5-dev-le...@gem5.org> > > > <mailto:gem5-dev-le...@gem5.org <mailto:gem5-dev- > > le...@gem5.org> > > > > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s > > > _______________________________________________ > > > gem5-dev mailing list -- gem5-dev@gem5.org <mailto:gem5- > > d...@gem5.org> <mailto:gem5- <mailto:gem5-> > > > d...@gem5.org <mailto:d...@gem5.org> > > > > To unsubscribe send an email to gem5-dev-le...@gem5.org > > <mailto:gem5-dev-le...@gem5.org> > > > <mailto:gem5-dev-le...@gem5.org <mailto:gem5-dev- > > le...@gem5.org> > > > > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s > > > > > > _______________________________________________ > > > gem5-dev mailing list -- gem5-dev@gem5.org <mailto:gem5- > > d...@gem5.org> <mailto:gem5- <mailto:gem5-> > > > d...@gem5.org <mailto:d...@gem5.org> > > > > To unsubscribe send an email to gem5-dev-le...@gem5.org > > <mailto:gem5-dev-le...@gem5.org> > > > <mailto:gem5-dev-le...@gem5.org <mailto:gem5-dev- > > le...@gem5.org> > > > > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s > > > > IMPORTANT NOTICE: The contents of this email and any attachments > > are confidential and may also be privileged. If you are not the intended > > recipient, please notify the sender immediately and do not disclose the > > contents to any other person, use it for any purpose, or store or copy > the > > information in any medium. Thank you. > > _______________________________________________ > > gem5-dev mailing list -- gem5-dev@gem5.org <mailto:gem5- > > d...@gem5.org> > > To unsubscribe send an email to gem5-dev-le...@gem5.org > > <mailto:gem5-dev-le...@gem5.org> > > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > _______________________________________________ > gem5-dev mailing list -- gem5-dev@gem5.org > To unsubscribe send an email to gem5-dev-le...@gem5.org > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
_______________________________________________ gem5-dev mailing list -- gem5-dev@gem5.org To unsubscribe send an email to gem5-dev-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
