Python coding style [was Re: [RFA] New python module gdb.types]

Python coding style [was Re: [RFA] New python module gdb.types]

[Doug Evans]

[note new subject line]

On Wed, Oct 6, 2010 at 2:11 PM, Joel Brobecker <brobecker@adacore.com> wrote:
> The python style is to not have a space before the opening parenthesis.
> [...]
> I think we should try to follow the Python style because it makes it
> easier for Python users to read our code.

Can we, at least as a first pass, adopt this?

http://google-styleguide.googlecode.com/svn/trunk/pyguide.html

Then I don't have to continually switch modes. :-)

[There may be parts that aren't applicable here, but as a first pass,
it's a good start.]

Re: Python coding style [was Re: [RFA] New python module gdb.types]

[Phil Muldoon]

On 10/06/2010 10:20 PM, Doug Evans wrote:
> [note new subject line]
> 
> On Wed, Oct 6, 2010 at 2:11 PM, Joel Brobecker <brobecker@adacore.com> wrote:
>> The python style is to not have a space before the opening parenthesis.
>> [...]
>> I think we should try to follow the Python style because it makes it
>> easier for Python users to read our code.
> 
> Can we, at least as a first pass, adopt this?
> 
> http://google-styleguide.googlecode.com/svn/trunk/pyguide.html
> 
> Then I don't have to continually switch modes. :-)
> 
> [There may be parts that aren't applicable here, but as a first pass,
> it's a good start.]

My deeply biased and very personal ideology her e is if how emacs
handles it.  Granted it is not the best representer of python style.
For my 2 pence worth, if the google style somehow replicates the emacs
representation of Python code, all the better.  OTOH I'm not sure if
any GNU standards represent Python at all.  Certainley the
libstdc++ printers are a little liberal wtih Python styles.

Cheers

Phil

Re: Python coding style [was Re: [RFA] New python module gdb.types]

[Joel Brobecker]

> 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. Even
if I did use emacs, 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/

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

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.

-- 
Joel

Re: Python coding style

[Tom Tromey]

Doug> Can we, at least as a first pass, adopt this?
Doug> http://google-styleguide.googlecode.com/svn/trunk/pyguide.html

It is ok with me.  I read through it and I thought it seemed reasonable
enough.

Can you say how it compares to PEP 8?

    http://www.python.org/dev/peps/pep-0008/

They seemed basically compatible to me, but I only spent a few minutes
with each.

Since you are more familiar with it, would you mind doing a little extra
review for changes to .py files for a while?  Some of the rules are
different enough from GNU C that it will take some getting used to;
e.g., the hanging indentation rule.


A couple specific exceptions:

* We shouldn't use the #!/usr/bin/env thing

* We should use FIXME instead of TODO, as the former is already gdb
  practice

Phil> My deeply biased and very personal ideology her e is if how emacs
Phil> handles it.

The defaults are mostly ok.  You'll need to set indent-tabs-mode to nil
in these buffers (though even this happens automatically with the
default settings).

Tom

Re: Python coding style [was Re: [RFA] New python module gdb.types]

[Phil Muldoon]

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

Re: Python coding style [was Re: [RFA] New python module gdb.types]

[Joel Brobecker]

> 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.

I think we are in a violent agreement, here. The Google guide is
interesting, not because of its (relatively short) section on formatting,
but because it gives some brief tips of things that we should or should
not do when writing Python code. My initial reaction when learning
Python was pretty negative because it wasn't the perfect language I was
lead to believe. If you read the "Learning Python" book, you'll find
that pretty much every chapter in that book has a "gotchas" section
at the end...

-- 
Joel

Re: Python coding style

[Doug Evans]

On Wed, Oct 6, 2010 at 3:25 PM, Tom Tromey <tromey@redhat.com> wrote:
> Doug> Can we, at least as a first pass, adopt this?
> Doug> http://google-styleguide.googlecode.com/svn/trunk/pyguide.html
>
> It is ok with me.  I read through it and I thought it seemed reasonable
> enough.
>
> Can you say how it compares to PEP 8?
>
>    http://www.python.org/dev/peps/pep-0008/
>
> They seemed basically compatible to me, but I only spent a few minutes
> with each.

AIUI there are a few incompatibilities.
e.g. pep says importing functions is ok, google style guide says only
import packages/modules.
I'm by no means an expert.

I think Google's guide specifies more, and specifies the reasons more.
We *could* reference both, and a blanket statement that X wins when
there's a conflict.
And then provide a supplement for gdb-specifics.
Easier than writing our own from scratch.

> Since you are more familiar with it, would you mind doing a little extra
> review for changes to .py files for a while?  Some of the rules are
> different enough from GNU C that it will take some getting used to;
> e.g., the hanging indentation rule.

If you wish.

> A couple specific exceptions:
>
> * We shouldn't use the #!/usr/bin/env thing

For my own education, why not?
[So I can document it in the style guide.]

> * We should use FIXME instead of TODO, as the former is already gdb
>  practice

Yeah.

> Phil> My deeply biased and very personal ideology her e is if how emacs
> Phil> handles it.
>
> The defaults are mostly ok.  You'll need to set indent-tabs-mode to nil
> in these buffers (though even this happens automatically with the
> default settings).

We should provide an emacs py mode that specifies our style.

Re: Python coding style

[Tom Tromey]

>>>>> "Doug" == Doug Evans <dje@google.com> writes:

Doug> I think Google's guide specifies more, and specifies the reasons more.
Doug> We *could* reference both, and a blanket statement that X wins when
Doug> there's a conflict.
Doug> And then provide a supplement for gdb-specifics.
Doug> Easier than writing our own from scratch.

Works for me.

Tom> * We shouldn't use the #!/usr/bin/env thing

Doug> For my own education, why not?
Doug> [So I can document it in the style guide.]

I think that is there so that a given module can be run standalone.
That won't work with a typical gdb-specific module, since they can't
typically even be imported when using the plain python executable.

Doug> We should provide an emacs py mode that specifies our style.

We could check a .dir-locals.el file into the tree.  I'm using this
right now:

((tcl-mode . ((tcl-indent-level . 4)
	      (tcl-continued-indent-level . 4)))
 (nil . ((bug-reference-url-format . "http://sourceware.org/bugzilla/show_bug.cgi?id=%s"))))

Tom