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
On Wed, Jul 1, 2020 at 2:03 PM Jean Abou Samra wrote:
> 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:
to me it's a no-brainer to introduce automatic
For automatic PEP8 formatting, there is
autopep8: https://pypi.org/project/autopep8/ and
yapf: https://pypi.org/project/yapf/
among others.
Cheers,
Joram
On Wed, Jul 1, 2020 at 10:55 AM Jean Abou Samra wrote:
> Hi Carl,
>
> Thanks for your reply.
> Le 01/07/2020 à 17:05, Carl Sorensen a écrit :
>
> Hi Jean,
>
> On Wed, Jul 1, 2020 at 6:03 AM Jean Abou Samra wrote:
>
>> Hi everybody,
>>
>> There
Hi Carl,
Thanks for your reply.
Le 01/07/2020 à 17:05, Carl Sorensen a écrit :
Hi Jean,
On Wed, Jul 1, 2020 at 6:03 AM Jean Abou Samra <mailto:j...@abou-samra.fr>> wrote:
Hi everybody,
There is some discussion in !212 about coding style inside our Python
Hi Jean,
On Wed, Jul 1, 2020 at 6:03 AM Jean Abou Samra wrote:
> Hi everybody,
>
> There is some discussion in !212 about coding style inside our Python
> scripts.
>
> The Contributor's Guide (10.5.1) clearly states that "Python code should
> use PEP 8". So, I'd
Hi everybody,
There is some discussion in !212 about coding style inside our Python
scripts.
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:
On 5/29/15 4:00 PM, David Kastrup d...@gnu.org wrote:
I also don't quite get what it never got officially adopted means in
light of commits like
commit cf137655b7aee9988ef536d6fa5e38d279ee73cf
Author: David Kastrup d...@gnu.org
Date: Mon Jun 10 17:28:51 2013 +0200
Run
Carl Sorensen c_soren...@byu.edu writes:
On 5/29/15 1:25 PM, Simon Albrecht simon.albre...@mail.de wrote:
Hello,
a while ago I found this document on what appear to be very widely
accepted standards for formatting scheme code:
http://community.schemewiki.org/?scheme-style. I find it very
Hello,
a while ago I found this document on what appear to be very widely
accepted standards for formatting scheme code:
http://community.schemewiki.org/?scheme-style. I find it very useful
and it seems to be altogether uncontroversial while warranting good
legibility.
Do we also accept
Am 29.05.2015 um 22:30 schrieb Thomas Morley:
2015-05-29 21:25 GMT+02:00 Simon Albrecht simon.albre...@mail.de:
Hello,
a while ago I found this document on what appear to be very widely accepted
standards for formatting scheme code:
http://community.schemewiki.org/?scheme-style. I find it very
On 5/29/15 1:25 PM, Simon Albrecht simon.albre...@mail.de wrote:
Hello,
a while ago I found this document on what appear to be very widely
accepted standards for formatting scheme code:
http://community.schemewiki.org/?scheme-style. I find it very useful
and it seems to be altogether
2015-05-29 21:25 GMT+02:00 Simon Albrecht simon.albre...@mail.de:
Hello,
a while ago I found this document on what appear to be very widely accepted
standards for formatting scheme code:
http://community.schemewiki.org/?scheme-style. I find it very useful and
it seems to be altogether
Am 29.05.2015 um 22:25 schrieb Carl Sorensen:
On 5/29/15 1:25 PM, Simon Albrecht simon.albre...@mail.de wrote:
Hello,
a while ago I found this document on what appear to be very widely
accepted standards for formatting scheme code:
http://community.schemewiki.org/?scheme-style. I find it
On 5/29/15 2:30 PM, Thomas Morley thomasmorle...@gmail.com wrote:
2015-05-29 21:25 GMT+02:00 Simon Albrecht simon.albre...@mail.de:
Hello,
a while ago I found this document on what appear to be very widely
accepted
standards for formatting scheme code:
I’ll come up with some text suggestions, or a patch, but not tonight.
Greetings, Simon
Am 29.05.2015 um 23:10 schrieb Carl Sorensen:
On 5/29/15 2:30 PM, Thomas Morley thomasmorle...@gmail.com wrote:
2015-05-29 21:25 GMT+02:00 Simon Albrecht simon.albre...@mail.de:
Hello,
a while ago I found
In this particular case it may not matter, but the
while ((flip(d) != UP)
is a common idiom in the lilypond source code
Chiming in on that; I think that we prefer these
patterns or idioms over specialisations.
Also, if you find a nice way of making the idiom nicer,
change it all over
Jan Nieuwenhuizen janneke-l...@xs4all.nl writes:
In this particular case it may not matter, but the
while ((flip(d) != UP)
is a common idiom in the lilypond source code
Chiming in on that; I think that we prefer these
patterns or idioms over specialisations.
In this particular case,
Hi,
in note-collision.cc I read the following:
Direction d = UP;
do
{
vectorGrob* clashes (clash_groups[d]);
vector_sort (clashes, Note_column::shift_less);
}
while ((flip (d)) != UP);
Uh, is there any reason not to just write
vector_sort (clash_groups[UP],
On Thu, Jan 13, 2011 at 7:19 PM, David Kastrup d...@gnu.org wrote:
Hi,
in note-collision.cc I read the following:
Direction d = UP;
do
{
vectorGrob* clashes (clash_groups[d]);
vector_sort (clashes, Note_column::shift_less);
}
while ((flip (d)) != UP);
Uh, is there
On Thu, Jan 13, 2011 at 10:19 AM, David Kastrup d...@gnu.org wrote:
Hi,
in note-collision.cc I read the following:
Direction d = UP;
do
{
vectorGrob* clashes (clash_groups[d]);
vector_sort (clashes, Note_column::shift_less);
}
while ((flip (d)) != UP);
Uh, is there
Han-Wen Nienhuys hanw...@gmail.com writes:
On Thu, Jan 13, 2011 at 10:19 AM, David Kastrup d...@gnu.org wrote:
Hi,
in note-collision.cc I read the following:
Direction d = UP;
do
{
vectorGrob* clashes (clash_groups[d]);
vector_sort (clashes, Note_column::shift_less);
On 13 Jan 2011, at 16:50, David Kastrup wrote:
Doesn't C++ have some more useful
idiom for iterators or so?
Then you'd have to write a function to apply. Below is an example; I
let you decide if it is more useful. :-)
Something like
for (d=UP;;d=DOWN) {
...
if (d == DOWN)
Hans Aberg haber...@telia.com writes:
On 13 Jan 2011, at 16:50, David Kastrup wrote:
Doesn't C++ have some more useful
idiom for iterators or so?
Then you'd have to write a function to apply. Below is an example; I
let you decide if it is more useful. :-)
Something like
for
Hi Graham,
scripts/build/create-version-itexi.py has a couple of coding style
nitpicks that should be fixed:
- every tab should be replaced with 4-spaces;
- duplicate definition of depth looks like a maintenance nightmare
similar to the issue Joe just reported on -devel;
- line[0:x] == should
2009/12/27 John Mandereau john.mander...@gmail.com:
- every tab should be replaced with 4-spaces;
- line[0:x] == should be replaced with more easy-to-write
line.startswith;
- uncleaned commented code that according to the comment doesn't work
with Python 2.4.5.
Done.
- duplicate definition
Le dimanche 27 décembre 2009 à 23:56 +, Graham Percival a écrit :
Done.
Thank you.
- duplicate definition of depth looks like a maintenance nightmare
similar to the issue Joe just reported on -devel;
That's not an issue; AFAIK the macros won't be used in a normal doc
build. If
2009/12/28 John Mandereau john.mander...@gmail.com:
Le dimanche 27 décembre 2009 à 23:56 +, Graham Percival a écrit :
- duplicate definition of depth looks like a maintenance nightmare
similar to the issue Joe just reported on -devel;
That's not an issue; AFAIK the macros won't be used
that the latter gets executed faster, at least if
no .pyc files are created.
Is this just convenience or is this a question of coding style?
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Op donderdag 01-01-2009 om 09:56 uur [tijdzone +0100], schreef Werner
LEMBERG:
? I could imagine that the latter gets executed faster, at least if
no .pyc files are created.
Faster is not interesting, most of the time.
Is this just convenience or is this a question of coding style
On Thu, Jan 1, 2009 at 6:56 AM, Werner LEMBERG w...@gnu.org wrote:
? I could imagine that the latter gets executed faster, at least if
no .pyc files are created.
Is this just convenience or is this a question of coding style?
The %s style gets hairy when there are lots of substitutions
We have a page on the website somewhere, that deals with this.
On Sun, Dec 28, 2008 at 9:13 PM, Werner LEMBERG w...@gnu.org wrote:
while I do not oppose to either change, I think it is important to
record the preference for either somewhere,
Where? Will document it then.
Werner
--
And to be superfluous, the coding style should usually be dictated by
the current style, but where we are not consistent, or where we're
changing conventions, it may make sense to document things.
On Sun, Dec 28, 2008 at 9:24 PM, Han-Wen Nienhuys hanw...@gmail.com wrote:
We have a page
form. :)
I suggest one of two options:
1) Ignore this issue for now, and revisit it in 3 weeks when I
get around to working on that part of the website.
2) Somebody (Werner?) takes reponsibility for the coding style
instructions, and either commits the texinfo to the web-gop/
branch directly
1) Ignore this issue for now, and revisit it in 3 weeks when I get
around to working on that part of the website.
OK. Please do a ping if you are ready for that.
2) Somebody (Werner?) takes reponsibility for the coding style
instructions, and either commits the texinfo to the web-gop
Coding style:
-) instead of accessing dicts by dict[key], use dict.get (key)
-) instead of try:... except KeyError:.. use dict.get (key) and test for None
afterwards
Cheers,
Reinhold
--
--
Reinhold Kainhofer, Vienna University
36 matches
Mail list logo
