lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Python coding style


From: Jean Abou Samra
Subject: Re: Python coding style
Date: Wed, 15 Jul 2020 21:33:43 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

Hi,

Le 02/07/2020 à 09:05, Han-Wen Nienhuys a écrit :
You can also do a global cleanup. We have done this in the past, but
it has the disadvantage that it makes history (eg. git-blame) harder
to read.


So, I did the global cleanup: https://gitlab.com/lilypond/lilypond/-/merge_requests/251

We can take it one bit at a time. In particular, if you can provide a
recipe that would reformat diffs, I can integrate that in my
pre-commit hook, so all new code is compliant.

I don't have that in my toolbox, sorry. The issue is that tools like autopep8 and YAPF work on ASTs, so they can't cope with incomplete bits of code. I don't know a safe way to pick just the part of the generated diff that deals with what
you change (if you see what I mean).

On Wed, Jul 1, 2020 at 2:03 PM Jean Abou Samra <jean@abou-samra.fr> wrote:
to me it's a no-brainer to introduce automatic formatting. I don't
really care what standard it enforces, as long as it is automated.

I would consider it, but it isn't a no-brainer to me: every automatic formatting tool has its issues, and I prefer formatting my code myself to format the way I think most human-readable.Anyway, let's rather discuss this later when we come to
adding a linter to CI.

- Use `string` instead of `str` as an identifier − `str` being a
built-in type
already.
This would be a good rule to follow if the Python team doesn't keep
adding identifiers to the top level scope. For example, in other
projects I had a lot of code become non-compliant overnight when
Python decided that binary formatting of number is worthy of the
toplevel identifier 'bin'.
I agree that Python evolves rapidly, but I think that `str` is common enough
to warrant not using as a variable since you could need it as its actual built-in value in your function. On the other hand, I didn't listen to pylint complaining
that we redefined the builtin `credits`.

Cheers,
Jean




reply via email to

[Prev in Thread] Current Thread [Next in Thread]