public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Phil Muldoon <pmuldoon@redhat.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: Doug Evans <dje@google.com>, gdb-patches@sourceware.org
Subject: Re: Python coding style [was Re: [RFA] New python module gdb.types]
Date: Thu, 07 Oct 2010 08:01:00 -0000	[thread overview]
Message-ID: <m3zkuqbfeq.fsf@redhat.com> (raw)
In-Reply-To: <20101006222337.GC2784@adacore.com> (Joel Brobecker's message of	"Wed, 6 Oct 2010 15:23:37 -0700")

Joel Brobecker <brobecker@adacore.com> writes:

>> My deeply biased and very personal ideology her e is if how emacs
>> handles it.
>
> I think it would be wrong to adopt that philosophy, and to be honest,
> I'm getting a little tired about having to suffer certain decisions
> purely because this is the default emacs indentation style. 

Well I did preface my comments with heavy disclaimers ;)  But I wasn't
aware this was such a controversial choice or that hackers had to suffer
for it.  FWIW I find the GNU C style somewhat hard to grok even now, after
years and using Emacs pretty consistently (with various forays to
Eclipse).  Anyway, I did not want to drag out history into the
conversation (unintentionally or not).

> I just think it's more important to be consistent
> with the rest of the Python community.
>
> There is actually an official Python Coding Style, called PEP8:
>
>     http://www.python.org/dev/peps/pep-0008/

That's great.  Good to see.

> I think we should strive to not break whatever suggestions this guide
> provides, and add some extra of our own if we feel necessary.

And I'll disagree here ;)  I think if we are striving to be consistent
with the community, adding a little of our own sauce should be a
question we should examine at least briefly. What I've read of the PEP
seems pretty comprehensive.  

> I looked at the Google Python Style Guide, and it does not conflict
> with PEP8. I also have relatively limited knowledge of Python, but
> I absolutely agree with everything in that document.

See above.

My own opinion is that we should purely not opt for one particular
flavor because there exists a vacuum.  Why not follow the PEP to the
letter? The Google guide looks sane, and really nice. But what are the
strong feelings the project should add this particular sauce over the
PEP? I just want to briefly examine those questions.

Finally I'll argue against my own point and note that Tom has mentioned
this will all work with Emacs anyway.  Maybe I am building a huge
straw-man.  But this is something that worries me a little bit.  Once
a standard is adopted (in particular a coding standard), it's usually
there forever.  

Cheers,

Phil

  reply	other threads:[~2010-10-07  8:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-06 21:21 Doug Evans
2010-10-06 21:37 ` Phil Muldoon
2010-10-06 22:23   ` Joel Brobecker
2010-10-07  8:01     ` Phil Muldoon [this message]
2010-10-08 15:17       ` Joel Brobecker
2010-10-06 22:25 ` Python coding style Tom Tromey
2010-10-08 21:20   ` Doug Evans
2010-10-08 21:35     ` Tom Tromey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3zkuqbfeq.fsf@redhat.com \
    --to=pmuldoon@redhat.com \
    --cc=brobecker@adacore.com \
    --cc=dje@google.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).