Oh, I certainly don't mean to block the purposed update. I'm sorry if it sounded that way. All I'm saying is we should add Python code style guides to it, and a follow up addendum can surely do the job.

On 14/03/2022 11:41, Josh McKenzie wrote:
+1 to the doc as written. A good portion of it also applies to python code style (structure, clarity in naming, etc).

Perhaps a python specific addendum as a follow up might make sense Bowen?

On Mon, Mar 14, 2022, at 7:21 AM, bened...@apache.org wrote:

I think the community would be happy to introduce a python style guide, but I am not well placed to do so, having chosen throughout my career to limit my exposure to python. Probably a parallel effort would be best - perhaps you could work with Stefan and others to produce such a proposal?



*From: *Bowen Song <bo...@bso.ng>
*Date: *Monday, 14 March 2022 at 10:53
*To: *dev@cassandra.apache.org <dev@cassandra.apache.org>
*Subject: *Re: Updating our Code Contribution/Style Guide

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:


     1. Deemphasis of getX() nomenclature, in favour of richer set of
        prefixes and more succinct simple x() to retrieve where clear
     2. Avoid implementing methods, incl. equals(), hashCode() and
        toString(), unless actually used
     3. Modified new-line rules for multi-line function calls
     4. External dependency rules (require DISCUSS thread before
        introducing)



Reply via email to