I think there's two separate issues, the style guide for Python code,
and fixing the existing code style. In my opinion, the style guide
should come first, and we can follow that to fix the existing code's style.
BTW, I can see the changes you made in CASSANDRA-17413 has already been
merged into trunk. However, latest code in trunk still has all the
issues I mentioned in the previous email. Some of the issues are purely
code styling, such as visual indentation and white spaces around
operators, but some are a little more than that, such as unused imports
which can slightly impact performance and memory usage.
I think there's two valid approaches to address the issue. We could
create a style guide first, and then fix them all in one go; or split
the issues to two categories, pure style issue to be fixed after the
code style guides is published, and other issues which can be fixed now.
I personally prefer the former, because it involves less amount of work
- no need to spend time to triage the issues reported by tools such as
"flake8".
On 14/03/2022 11:11, Stefan Miklosovic wrote:
Hi Bowen,
we were working on that recently, like CASSANDRA-17413 + a lot of
improvements around Python stuff are coming. If you identify more
places for improvements we are definitely interested.
Regards
On Mon, 14 Mar 2022 at 11:53, Bowen Song <bo...@bso.ng> wrote:
I found there's no mentioning of Python code style at all. If we are going to
update the style guide, can this be addressed too?
FYI, a quick "flake8" style check shows many existing issues in the Python
code, including libraries imported but unused, redefinition of unused imports and invalid
escape sequence in strings.
On 14/03/2022 09:41, bened...@apache.org wrote:
Our style guide hasn’t been updated in about a decade, and I think it is
overdue some improvements that address some shortcomings as well as modern
facilities such as streams and lambdas.
Most of this was put together for an effort Dinesh started a few years ago, but
has languished since, in part because the project has always seemed to have
other priorities. I figure there’s never a good time to raise a contended
topic, so here is my suggested update to contributor guidelines:
https://docs.google.com/document/d/1sjw0crb0clQin2tMgZLt_ob4hYfLJYaU4lRX722htTo
Many of these suggestions codify norms already widely employed, sometimes in
spite of the style guide, but some likely remain contentious. Some potentially
contentious things to draw your attention to:
Deemphasis of getX() nomenclature, in favour of richer set of prefixes and more
succinct simple x() to retrieve where clear
Avoid implementing methods, incl. equals(), hashCode() and toString(), unless
actually used
Modified new-line rules for multi-line function calls
External dependency rules (require DISCUSS thread before introducing)
