[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Python coding style
Re: Python coding style
Wed, 1 Jul 2020 09:05:24 -0600
On Wed, Jul 1, 2020 at 6:03 AM Jean Abou Samra <email@example.com> wrote:
> Hi everybody,
> There is some discussion in !212 about coding style inside our Python
> The Contributor's Guide (10.5.1) clearly states that "Python code should
> use PEP 8". So, I'd like to be sure everyone agrees on the following points
> which are part of applying this PEP:
> - Remove spaces before the opening parenthesis in function calls and
> e.g., f(x) instead of f (x).
I believe we should definitely follow PEP here. And ideally we should have
a code formatter that does this for us, so we don't rely on people
remembering that PEP is different from GNU C standarads.
> - Use `string` instead of `str` as an identifier − `str` being a
> built-in type
> already. Also common is `s`, but the Contributor's Guide also says (10.5.4)
> that "Variable names should be complete words, rather than abbreviations."
> (which is basically concerned with C++, but that particular rule is, in my
> opinion, valid for Python too). In particular, this applies to
I can agree that it is wrong to use 'str', since 'str' is a built in type.
In my opinion, for convertrules.py, we shoud just use 's', not 'string'.
Even if we use the complete word 'string', there is no special meaning in
it (it's not a special string, it's just a generic string). I believe it's
analogous to using 'i' for an index in a c++ loop.
> - Use the standard naming conventions, especially CamelCase for class
> names (the
> current style being a mixture of CamelCase and sometimes
> First_word_capitalized_with_underscores). Write module-level constants in
> UPPERCASE_WITH_UNDERSCORES. Likewise, change things like
> class error (Exception): pass
> class MIDIConversionError(Exception):
> In CamelCase names that contain acronyms, capitalize all letters of the
> (thus, the previous example doesn't read 'MidiConversionError').
> I think we should follow the standard here.
> There are many specific changes that could be done to improve style and
> (such as replacing `ls = list(something); ls.sort()` with `ls =
> etc.), but the above could be made in general commits fixing all Python
I would be supportive of changes to improve style and readability, but
might question if it's worth the time. However, I'd support anybody who
wants to scratch that itch.
Making things compatible with PEP8 is certainly a good idea.