[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Standardizing our Python code style

From: Bhuvaneswaran A <bhuvan_at_collab.net>
Date: Fri, 23 Oct 2009 00:07:16 +0530

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

Received on 2009-10-22 20:37:28 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.