You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Blair Zajac <bl...@orcaware.com> on 2009/10/21 22:09:23 UTC
Standardizing our Python code style
We've got a bunch of different Python styles in our code, and as we have a C
coding style, I'd like to propose we standardize the Python code using the style
guide at python.org so we don't have to switch between different styles in the
project:
http://www.python.org/doc/essays/styleguide.html
http://www.python.org/dev/peps/pep-0008/
http://www.python.org/dev/peps/pep-0257/
Regards,
Blair
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2409985
Re: Standardizing our Python code style
Posted by Barry Scott <ba...@barrys-emacs.org>.
On 22 Oct 2009, at 19:37, Bhuvaneswaran A wrote:
> All sounds like an excellent checklist to me.
>
> I'd also go 1 step ahead and use pylint tool to validate all our
> python
> scripts. We may have a pylintrc configuration file in our repository
> that defines all these standards (and more) as a rule. We may have a
> benchmark for pylint score (10/10?) for any python script that goes in
> the repository! -:)
>
My experience with pylint is that it raises a huge number of false
positive
and false negative reports. These need human filtering to find the gems.
Also beware that pylint imposes style checks that may well conflict with
subversions coding style.
Only trivial code will pass clean.
pychecker is better, but not perfect either.
Barry
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2410853
Re: Standardizing our Python code style
Posted by Bhuvaneswaran A <bh...@collab.net>.
All sounds like an excellent checklist to me.
I'd also go 1 step ahead and use pylint tool to validate all our python
scripts. We may have a pylintrc configuration file in our repository
that defines all these standards (and more) as a rule. We may have a
benchmark for pylint score (10/10?) for any python script that goes in
the repository! -:)
On Thu, 2009-10-22 at 10:58 -0700, Blair Zajac wrote:
> Julian Foad wrote:
> > Blair Zajac wrote:
> >> We've got a bunch of different Python styles in our code, and as we have a C
> >> coding style, I'd like to propose we standardize the Python code using the style
> >> guide at python.org so we don't have to switch between different styles in the
> >> project:
> >>
> >> http://www.python.org/doc/essays/styleguide.html
> >> http://www.python.org/dev/peps/pep-0008/
> >> http://www.python.org/dev/peps/pep-0257/
> >
> > To get us started, can you summarize the top few inconsistencies, and
> > which way we should do each of those things? +1 on consistency, +1 on
> > following the commonly used style guides, but -1 on everyone having to
> > digest the complete style guides before making their next patch.
>
> The largest inconsistency is 2-space versus 4-space indentation, where 4-space
> is the standard. If you're short on time, just read PEP-8, don't bother with
> the other one.
>
> The major ones, in my opinion from PEP-8 are the following:
>
> Indentation
>
> Use 4 spaces per indentation level.
>
> Tabs or Spaces?
>
> Never mix tabs and spaces.
>
> Maximum Line Length
>
> Limit all lines to a maximum of 79 characters.
>
> Imports
>
> - Imports should usually be on separate lines, e.g.:
>
> Yes: import os
> import sys
>
> Imports should be grouped in the following order:
>
> 1. standard library imports
> 2. related third party imports
> 3. local application/library specific imports
>
>
> Pet Peeves
>
> Avoid extraneous whitespace in the following situations:
>
> - Immediately inside parentheses, brackets or braces.
>
> Yes: spam(ham[1], {eggs: 2})
> No: spam( ham[ 1 ], { eggs: 2 } )
>
> - Immediately before a comma, semicolon, or colon:
>
> Yes: if x == 4: print x, y; x, y = y, x
> No: if x == 4 : print x , y ; x , y = y , x
>
> - Immediately before the open parenthesis that starts the argument
> list of a function call:
>
> Yes: spam(1)
> No: spam (1)
>
> - Immediately before the open parenthesis that starts an indexing or
> slicing:
>
> Yes: dict['key'] = list[index]
> No: dict ['key'] = list [index]
>
> - More than one space around an assignment (or other) operator to
> align it with another.
>
> Yes:
>
> x = 1
> y = 2
> long_variable = 3
>
> No:
>
> x = 1
> y = 2
> long_variable = 3
>
> Other Recommendations
>
> - Always surround these binary operators with a single space on
> either side: assignment (=), augmented assignment (+=, -= etc.),
> comparisons (==, <, >, !=, <>, <=, >=, in, not in, is, is not),
> Booleans (and, or, not).
>
> - Use spaces around arithmetic operators:
>
> Yes:
>
> i = i + 1
> submitted += 1
> x = x * 2 - 1
> hypot2 = x * x + y * y
> c = (a + b) * (a - b)
>
> No:
>
> i=i+1
> submitted +=1
> x = x*2 - 1
> hypot2 = x*x + y*y
> c = (a+b) * (a-b)
>
> - Don't use spaces around the '=' sign when used to indicate a
> keyword argument or a default parameter value.
>
> Yes:
>
> def complex(real, imag=0.0):
> return magic(r=real, i=imag)
>
> No:
>
> def complex(real, imag = 0.0):
> return magic(r = real, i = imag)
>
>
> - Object type comparisons should always use isinstance() instead
> of comparing types directly.
>
> Yes: if isinstance(obj, int):
>
> No: if type(obj) is type(1):
>
> - For sequences, (strings, lists, tuples), use the fact that empty
> sequences are false.
>
> Yes: if not seq:
> if seq:
>
> No: if len(seq)
> if not len(seq)
>
> - Don't compare boolean values to True or False using ==
>
> Yes: if greeting:
>
> No: if greeting == True:
>
> Worse: if greeting is True:
>
> - Comparisons to singletons like None should always be done with
> 'is' or 'is not', never the equality operators.
>
> Blair
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2410333
--
Bhuvaneswaran A
CollabNet Software P Ltd. | www.collab.net
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2410353
Re: Standardizing our Python code style
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Oct 22, 2009 at 16:38, Greg Hudson <gh...@mit.edu> wrote:
> On Thu, 2009-10-22 at 15:51 -0400, Greg Stein wrote:
>> I'm going to stick to 2-space. That's what Guido himself uses, so if
>> it is good enough for him, then it's good enough for me :-D
>
> He does? It seemed odd to me that a language would have an official
> style guide so fundamentally at odds with the language's creator, so I
> googled around, and found only evidence that Guido favors four-space
> indentation. Specifically:
>
> * The Python code style guide (PEP-8) was originally written by Guido,
> although it now has two authors and the original is not available:
> http://www.python.org/dev/peps/pep-0008/
>
> * The C style guide for the Python implementation was written by Guido,
> and pushes four-space indents: http://www.python.org/dev/peps/pep-0007/
>
> * A discussion of enforcing indentation style in the Python interpreter
> (rejected) referenced Guido as pushing four-space indentation:
> http://www.velocityreviews.com/forums/t690805-why-not-enforce-four-space-indentations-in-version-3x.html
>
> * http://www.peterbe.com/plog/Google-and-python-code complains that:
>
> All Python code from Google Code uses 2 spaces (not tabs) and
> that's not what Guido uses or recommends.
Hunh! I swear when I was talking to him, he said "2 spaces". I betcha
that I'm misremembering, and he was just saying he'd follow the
2-space style that Google uses. (and that I can definitely confirm; I
was a style reviewer while there)
Thanks for fixing my doddering old memory! :-P
Cheers,
-g
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2410444
Re: Standardizing our Python code style
Posted by Greg Hudson <gh...@mit.edu>.
On Thu, 2009-10-22 at 15:51 -0400, Greg Stein wrote:
> I'm going to stick to 2-space. That's what Guido himself uses, so if
> it is good enough for him, then it's good enough for me :-D
He does? It seemed odd to me that a language would have an official
style guide so fundamentally at odds with the language's creator, so I
googled around, and found only evidence that Guido favors four-space
indentation. Specifically:
* The Python code style guide (PEP-8) was originally written by Guido,
although it now has two authors and the original is not available:
http://www.python.org/dev/peps/pep-0008/
* The C style guide for the Python implementation was written by Guido,
and pushes four-space indents: http://www.python.org/dev/peps/pep-0007/
* A discussion of enforcing indentation style in the Python interpreter
(rejected) referenced Guido as pushing four-space indentation:
http://www.velocityreviews.com/forums/t690805-why-not-enforce-four-space-indentations-in-version-3x.html
* http://www.peterbe.com/plog/Google-and-python-code complains that:
All Python code from Google Code uses 2 spaces (not tabs) and
that's not what Guido uses or recommends.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2410420
Re: Standardizing our Python code style
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Oct 22, 2009 at 13:58, Blair Zajac <bl...@orcaware.com> wrote:
>...
> The largest inconsistency is 2-space versus 4-space indentation, where 4-space
> is the standard. If you're short on time, just read PEP-8, don't bother with
> the other one.
I'm going to stick to 2-space. That's what Guido himself uses, so if
it is good enough for him, then it's good enough for me :-D
The rest... *shrug*
Cheers,
-g
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2410398
Re: Standardizing our Python code style
Posted by Blair Zajac <bl...@orcaware.com>.
Julian Foad wrote:
> Blair Zajac wrote:
>> We've got a bunch of different Python styles in our code, and as we have a C
>> coding style, I'd like to propose we standardize the Python code using the style
>> guide at python.org so we don't have to switch between different styles in the
>> project:
>>
>> http://www.python.org/doc/essays/styleguide.html
>> http://www.python.org/dev/peps/pep-0008/
>> http://www.python.org/dev/peps/pep-0257/
>
> To get us started, can you summarize the top few inconsistencies, and
> which way we should do each of those things? +1 on consistency, +1 on
> following the commonly used style guides, but -1 on everyone having to
> digest the complete style guides before making their next patch.
The largest inconsistency is 2-space versus 4-space indentation, where 4-space
is the standard. If you're short on time, just read PEP-8, don't bother with
the other one.
The major ones, in my opinion from PEP-8 are the following:
Indentation
Use 4 spaces per indentation level.
Tabs or Spaces?
Never mix tabs and spaces.
Maximum Line Length
Limit all lines to a maximum of 79 characters.
Imports
- Imports should usually be on separate lines, e.g.:
Yes: import os
import sys
Imports should be grouped in the following order:
1. standard library imports
2. related third party imports
3. local application/library specific imports
Pet Peeves
Avoid extraneous whitespace in the following situations:
- Immediately inside parentheses, brackets or braces.
Yes: spam(ham[1], {eggs: 2})
No: spam( ham[ 1 ], { eggs: 2 } )
- Immediately before a comma, semicolon, or colon:
Yes: if x == 4: print x, y; x, y = y, x
No: if x == 4 : print x , y ; x , y = y , x
- Immediately before the open parenthesis that starts the argument
list of a function call:
Yes: spam(1)
No: spam (1)
- Immediately before the open parenthesis that starts an indexing or
slicing:
Yes: dict['key'] = list[index]
No: dict ['key'] = list [index]
- More than one space around an assignment (or other) operator to
align it with another.
Yes:
x = 1
y = 2
long_variable = 3
No:
x = 1
y = 2
long_variable = 3
Other Recommendations
- Always surround these binary operators with a single space on
either side: assignment (=), augmented assignment (+=, -= etc.),
comparisons (==, <, >, !=, <>, <=, >=, in, not in, is, is not),
Booleans (and, or, not).
- Use spaces around arithmetic operators:
Yes:
i = i + 1
submitted += 1
x = x * 2 - 1
hypot2 = x * x + y * y
c = (a + b) * (a - b)
No:
i=i+1
submitted +=1
x = x*2 - 1
hypot2 = x*x + y*y
c = (a+b) * (a-b)
- Don't use spaces around the '=' sign when used to indicate a
keyword argument or a default parameter value.
Yes:
def complex(real, imag=0.0):
return magic(r=real, i=imag)
No:
def complex(real, imag = 0.0):
return magic(r = real, i = imag)
- Object type comparisons should always use isinstance() instead
of comparing types directly.
Yes: if isinstance(obj, int):
No: if type(obj) is type(1):
- For sequences, (strings, lists, tuples), use the fact that empty
sequences are false.
Yes: if not seq:
if seq:
No: if len(seq)
if not len(seq)
- Don't compare boolean values to True or False using ==
Yes: if greeting:
No: if greeting == True:
Worse: if greeting is True:
- Comparisons to singletons like None should always be done with
'is' or 'is not', never the equality operators.
Blair
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2410333
Re: Standardizing our Python code style
Posted by Julian Foad <ju...@btopenworld.com>.
Blair Zajac wrote:
> We've got a bunch of different Python styles in our code, and as we have a C
> coding style, I'd like to propose we standardize the Python code using the style
> guide at python.org so we don't have to switch between different styles in the
> project:
>
> http://www.python.org/doc/essays/styleguide.html
> http://www.python.org/dev/peps/pep-0008/
> http://www.python.org/dev/peps/pep-0257/
To get us started, can you summarize the top few inconsistencies, and
which way we should do each of those things? +1 on consistency, +1 on
following the commonly used style guides, but -1 on everyone having to
digest the complete style guides before making their next patch.
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2410135
Re: Standardizing our Python code style
Posted by Greg Stein <gs...@gmail.com>.
Big +1
On Wed, Oct 21, 2009 at 18:09, Blair Zajac <bl...@orcaware.com> wrote:
> We've got a bunch of different Python styles in our code, and as we have a C
> coding style, I'd like to propose we standardize the Python code using the style
> guide at python.org so we don't have to switch between different styles in the
> project:
>
> http://www.python.org/doc/essays/styleguide.html
> http://www.python.org/dev/peps/pep-0008/
> http://www.python.org/dev/peps/pep-0257/
>
> Regards,
> Blair
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2409985
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2410013
Re: Standardizing our Python code style
Posted by Branko Cibej <br...@xbc.nu>.
Blair Zajac wrote:
> We've got a bunch of different Python styles in our code, and as we have a C
> coding style, I'd like to propose we standardize the Python code using the style
> guide at python.org so we don't have to switch between different styles in the
> project:
>
> http://www.python.org/doc/essays/styleguide.html
> http://www.python.org/dev/peps/pep-0008/
> http://www.python.org/dev/peps/pep-0257/
>
I agree, that is, +1. However I would make our guidelines just a teeny
bit stricter, to the tune of forbidding tabs in the Python source files,
like we do in C source files.
-- Brane
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2410348