I'm searching for Python style guidelines
MartinR...@gmail.com
efficiently ..." Thanks, I'll keep that in mind.
van Rossum's guidelines tend toward "pick something and stick to it"
which is OK if you have enough experience to pick something Pythonic.
I'm a relative newbie, not qualified to pick.
Anything written somewhere that's thorough? Any code body that should
serve as a reference?
Peter Otten
> Anything written somewhere that's thorough? Any code body that should
> serve as a reference?
Guilherme Polo
PEP 8
http://www.python.org/dev/peps/pep-0008/
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
-- Guilherme H. Polo Goncalves
MartinR...@gmail.com
Stupid me, went to Python.org and found Style Guidelines and thought
that was the last word. Oh well.
PEP 8 reminds me a lot of Sun's Java conventions, in ways I wish it
didn't. The overall structure seems like a random list of topics and
it omits a lot. For Java I went from Sun to other conventions to try
to compile a meta-convention ( http://www.MartinRinehart.com/articles/code-conventions.html
).
Here's just one of my questions:
foo = [
'some item, quite long',
'more items, all demanding there own line as they are not short',
...
Where would you put the closing ']'?
Fredrik Lundh
> Here's just one of my questions:
>
> foo = [
> 'some item, quite long',
> 'more items, all demanding there own line as they are not short',
> ...
>
> Where would you put the closing ']'?
on a line by itself, indented as your favourite Python editor indents it.
</F>
Guilherme Polo
I would put ']' at a new line:
foo = [
'too long',
'too long too',
...
]
I don't really believe it should exist style guidelines for everything
that is possible (or if it did I doubt it would matter), many/most
people adapt the guidelines to fetch their own style. That is not
really a problem if you are consistent during all the code, and if it
is not too ugly as well =)
MartinR...@gmail.com
Guilherme Polo wrote:
> foo = [
> 'too long',
> 'too long too',
> ...
> ]
OK, I'll put it there too, and it will be easy for us to read each
other's code (at least in this particular).
Paul McGuire
While not required by any means, you will also find it handy to follow
*every* entry in the list with a comma, even the last one in the list
(this is legal Python). That is, in your example:
foo = [
'too long',
'too long too',
'too long too',
'last item',
]
Later on when you want to reorder the items, then you can just copy/
paste whole lines, even if moving to or from the bottom of the list.
This is also a good argument for putting the closing ']' on its own
line, instead of on the same line as the last item.
-- Paul
ajaksu
I've done this search before and it was very interesting, doing it
again gave me new results that also seem valuable. Here's most of them
(where PCG = Python Coding Guidelines).
Cogent project PCG
http://jaynes.colorado.edu/PythonGuidelines.html
(also http://jaynes.colorado.edu/PythonIdioms.html)
Freevo Coding Standard
http://doc.freevo.org/CodingStandard
Mercurial Basic Coding Style
http://www.selenic.com/mercurial/wiki/index.cgi/Basic_Coding_Style
PyBlosxom Coding Style Guide
http://pyblosxom.sourceforge.net/blog/static/development#coding
MoinMoin Coding Style
http://moinmoin.wikiwikiweb.de/CodingStyle
Webware Style Guidelines
http://www.webwareforpython.org/Docs/StyleGuidelines.html
NOAA Enhanced Forecaster Tools PCG
http://www-md.fsl.noaa.gov/eft/developer/PythonCodingStandards.html
BioPython Coding Conventions
http://biopython.org/wiki/Contributing#Coding_conventions
Mnet PCG
http://mnet.sourceforge.net/coding_standards.html
Michael Foord's (aka Voidspace) PCG
http://www.voidspace.org.uk/python/weblog/arch_d7_2006_04_01.shtml#e296
SQLObject Coding Style
http://www.sqlobject.org/DeveloperGuide.html#style-guide
WxPython PCG
http://www.wxpython.org/codeguidelines.php
Python coding style guide for Mailman
http://barry.warsaw.us/software/STYLEGUIDE.txt
VoiceCode PCG
http://voicecode.iit.nrc.ca/VoiceCode/uploads/codingGuidelines.html
Bazaar Coding Stile Guidelines
http://doc.bazaar-vcs.org/bzr.dev/en/developer-guide/HACKING.html#coding-style-guidelines
IPython Developer Guidelines
http://ipython.scipy.org/moin/Developer_Zone/Developer_Guidelines
OSAF Chandler PCG
http://chandlerproject.org/Projects/ChandlerCodingStyleGuidelines
(along with http://chandlerproject.org/Projects/ChandlerEpydocStyleGuide)
Twisted Coding Standard
http://twistedmatrix.com/trac/browser/trunk/doc/development/policy/coding-standard.xhtml?format=raw
PyPy RPython and CPython Coding Guidelines
http://codespeak.net/pypy/dist/pypy/doc/coding-guide.html
Django PCG (and general contribution recommendations)
http://www.djangoproject.com/documentation/contributing/#coding-style
Docutils PCG
http://docutils.sourceforge.net/docs/dev/policies.html#python-coding-conventions
Trac Coding Style
http://trac.edgewall.org/wiki/TracDev/CodingStyle
OLPC PCG
http://wiki.laptop.org/go/Python_Style_Guide
Skeletonz Coding and Naming Conventions
http://orangoo.com/skeletonz/Developer_guide/Coding_convention/
http://orangoo.com/skeletonz/Developer_guide/Naming_convention/
CherryPy Code Conventions
http://www.cherrypy.org/wiki/CodeConventions
More generic but still good (or great) insights:
Software Carpentry on style http://www.swc.scipy.org/lec/style.html
Zope's Coding Style http://wiki.zope.org/zope3/CodingStyle
The docstrings PEP http://www.python.org/dev/peps/pep-0257/
The NiceStyle Triad®:
Pyflakes http://divmod.org/trac/wiki/DivmodPyflakes
PyChecker http://pychecker.sourceforge.net/
Pylint http://www.logilab.org/857
Do you think this could be a valuable addition to the Python wiki?
HTH,
Daniel
Ben Finney
> I've done this search before and it was very interesting, doing it
> again gave me new results that also seem valuable. Here's most of
> them (where PCG = Python Coding Guidelines).
Thanks, this is an awesome list. It's good to have a variety of real
examples when drafting a coding standard for a project.
> Do you think this could be a valuable addition to the Python wiki?
Definitely!
--
\ "The most merciful thing in the world... is the inability of |
`\ the human mind to correlate all its contents." -- Howard |
_o__) Philips Lovecraft |
Ben Finney
grflanagan
> On Jan 7, 11:25 am, MartinRineh...@gmail.com wrote:
>
> > Anything written somewhere that's thorough? Any code body that should
> > serve as a reference?
>
> I've done this search before and it was very interesting, doing it
> again gave me new results that also seem valuable. Here's most of them
> (where PCG = Python Coding Guidelines).
[...]
>
> Do you think this could be a valuable addition to the Python wiki?
>
+1, absolutely
Here's the list in rest format:
------------------------------
FOSS Projects Style Guidelines
------------------------------
`Cogent project PCG`__
.. _Cogent PCG: http://jaynes.colorado.edu/PythonGuidelines.html
__ `Cogent PCG`_
`Cogent project Python Idioms`__
.. _Cogent Idioms: http://jaynes.colorado.edu/PythonIdioms.html
__ `Cogent Idioms`_
`Freevo Coding Standard`__
.. _Freevo PCG: http://doc.freevo.org/CodingStandard
__ `Freevo PCG`_
`Mercurial Basic Coding Style`__
.. _Mercurial PCG: http://www.selenic.com/mercurial/wiki/index.cgi/Basic_Coding_Style
__ `Mercurial PCG`_
`PyBlosxom Coding Style Guide`__
.. _PyBlosxom PCG: http://pyblosxom.sourceforge.net/blog/static/development#coding
__ `PyBlosxom PCG`_
`MoinMoin Coding Style`__
.. _MoinMoin PCG: http://moinmoin.wikiwikiweb.de/CodingStyle
__ `MoinMoin PCG`_
`Webware Style Guidelines`__
.. _Webware PCG: http://www.webwareforpython.org/Docs/StyleGuidelines.html
__ `Webware PCG`_
`NOAA Enhanced Forecaster Tools PCG`__
.. _NOAA PCG: http://www-md.fsl.noaa.gov/eft/developer/PythonCodingStandards.html
__ `NOAA PCG`_
`BioPython Coding Conventions`__
.. _BioPython PCG: http://biopython.org/wiki/Contributing#Coding_conventions
__ `BioPython PCG`_
`Mnet PCG`__
.. _Mnet PCG: http://mnet.sourceforge.net/coding_standards.html
__ `Mnet PCG`_
`Michael Foord's (aka Voidspace) PCG`__
.. _Michael PCG: http://www.voidspace.org.uk/python/weblog/arch_d7_2006_04_01.shtml#e296
__ `Michael PCG`_
`SQLObject Coding Style`__
.. _SQLObject PCG: http://www.sqlobject.org/DeveloperGuide.html#style-guide
__ `SQLObject PCG`_
`WxPython PCG`__
.. _WxPython PCG: http://www.wxpython.org/codeguidelines.php
__ `WxPython PCG`_
`Mailman PCG`__
.. _Mailman PCG: http://barry.warsaw.us/software/STYLEGUIDE.txt
__ `Mailman PCG`_
`VoiceCode PCG`__
.. _VoiceCode PCG: http://voicecode.iit.nrc.ca/VoiceCode/uploads/codingGuidelines.html
__ `VoiceCode PCG`_
`Bazaar Coding Style Guidelines`__
.. _Bazaar PCG: http://doc.bazaar-vcs.org/bzr.dev/en/developer-guide/HACKING.html#coding-style-guidlines
__ `Bazaar PCG`_
`IPython Developer Guidelines`__
.. _IPython PCG: http://ipython.scipy.org/moin/Developer_Zone/Developer_Guidelines
__ `IPython PCG`_
`OSAF Chandler PCG`__
.. _OSAF PCG: http://chandlerproject.org/Projects/ChandlerCodingStyleGuidelines
__ `OSAF PCG`_
`OSAF Chandler Epydoc Style Guide`__
.. _OSAF Epydoc: http://chandlerproject.org/Projects/ChandlerEpydocStyleGuide
__ `OSAF Epydoc`_
`Twisted Coding Standard`__
.. _Twisted PCG: http://twistedmatrix.com/trac/browser/trunk/doc/development/policy/coding-standard.xhtml?format=raw
__ `Twisted PCG`_
`PyPy RPython and CPython Coding Guidelines`__
.. _PyPy PCG: http://codespeak.net/pypy/dist/pypy/doc/coding-guide.html
__ `PyPy PCG`_
`Django PCG`__
.. _Django PCG: http://www.djangoproject.com/documentation/contributing/#coding-style
__ `Django PCG`_
`Docutils PCG`__
.. _Docutils PCG: http://docutils.sourceforge.net/docs/dev/policies.html#python-coding-conventions
__ `Docutils PCG`_
`Trac Coding Style`__
.. _Trac PCG: http://trac.edgewall.org/wiki/TracDev/CodingStyle
__ `Trac PCG`_
`OLPC PCG`__
.. _OLPC PCG: http://wiki.laptop.org/go/Python_Style_Guide
__ `OLPC PCG`_
`Skeletonz Coding and Naming Conventions`__
.. _Skeletonz PCG: http://orangoo.com/skeletonz/Developer_guide/Coding_convention/
__ `Skeletonz PCG`_
`CherryPy Code Conventions`__
.. _CherryPy PCG: http://www.cherrypy.org/wiki/CodeConventions
__ `CherryPy PCG`_
`Software Carpentry on style`__
.. _Software Carpentry PCG: http://www.swc.scipy.org/lec/style.html
__ `Software Carpentry PCG`_
`Zope's Coding Style`__
.. _Zope PCG: http://wiki.zope.org/zope3/CodingStyle
__ `Zope PCG`_
`The docstrings PEP`__
.. _docstrings: http://www.python.org/dev/peps/pep-0257/
__ `docstrings`_
`Pyflakes`__
.. _Pyflakes: http://divmod.org/trac/wiki/DivmodPyflakes
__ `Pyflakes`_
`PyChecker`__
.. _PyChecker: http://pychecker.sourceforge.net/
__ `PyChecker`_
`Pylint`__
.. _Pylint: http://www.logilab.org/857
__ `Pylint`_
MartinR...@gmail.com
I looked at each and copied to my disk either as a .txt (cut/paste
from the browser) for a page or less or as .html (view source, chop
off head and non-guideline stuff, save). This is the list plus PEP 8
minus the software. (No disrespect for the software, just sticking to
written standards.) Zope may be a substantial guideline, but it linked
to a page of Zope links, all of which were broken.
This CSV file is sorted by filesize on my disk. One presumes that a
relationship exists between size and extent of coverage. (Warning:
Wiki text could be as much as twice the size of non-wiki for the same
content.) The third column is empty (spacer between size and URL).
A quick look (thorough analysis still required) shows that OLPC and
PyPy are, indeed, extensive standards.
one-laptop-per-child.html (olpc),74.3,,http://wiki.laptop.org/go/
Python_Style_Guide
pypy.html,64.2,,http://codespeak.net/pypy/dist/pypy/doc/coding-
guide.html
pep-008.html,35.6,,http://www.python.org/dev/peps/pep-0008/
knight.html,33.7,,http://jaynes.colorado.edu/PythonGuidelines.html
pep-257.html,23.8,,http://www.python.org/dev/peps/pep-0257/
webware.html,23.4,,http://www.webwareforpython.org/Docs/
StyleGuidelines.html
twisted.html,23.3,,http://twistedmatrix.com/trac/browser/trunk/doc/
development/policy/co...
voice-code.html,17.9,,http://voicecode.iit.nrc.ca/VoiceCode/uploads/
codingGuidelines.html
fsl.html,15.0,,http://www-md.fsl.noaa.gov/eft/developer/
PythonCodingStandards.html
wx.html,14.6,,http://www.wxpython.org/codeguidelines.php
mnet.html,14.5,,http://mnet.sourceforge.net/coding_standards.html
michael-foord.html,14.2,,http://www.voidspace.org.uk/python/weblog/
arch_d7_2006_04_01.shtml#e296
bazaar.html,10.4,,http://doc.bazaar-vcs.org/bzr.dev/en/developer-guide/
HACKING.html#cod...
ipython.html,10.2,,http://ipython.scipy.org/moin/Developer_Zone/
Developer_Guidelines
barry-warsaw.html,6.2,,http://barry.warsaw.us/software/STYLEGUIDE.txt
django.html,5.6,,http://www.djangoproject.com/documentation/
contributing/#coding-style
chandler.txt,4.0,,http://chandlerproject.org/Projects/
ChandlerCodingStyleGuidelines
pyblosxom.txt,3.8,,http://pyblosxom.sourceforge.net/blog/static/
development#coding
freevo.txt,3.4,,http://jaynes.colorado.edu/PythonGuidelines.html
sql-object.txt,2.7,,http://www.sqlobject.org/DeveloperGuide.html#style-
guide
biopython.txt,2.5,,http://biopython.org/wiki/
Contributing#Coding_conventions
tracdev.txt,1.8,,http://trac.edgewall.org/wiki/TracDev/CodingStyle
docutils,1.8,,http://docutils.sourceforge.net/docs/dev/
policies.html#python-coding-...
moinmoin.txt,1.8,,http://moinmoin.wikiwikiweb.de/CodingStyle
cherrypy.txt,1.5,,http://www.cherrypy.org/wiki/CodeConventions
skeletonz-naming.txt,1.4,,http://orangoo.com/skeletonz/Developer_guide/
Naming_convention/
mercurial.txt,0.9,,http://www.selenic.com/mercurial/wiki/index.cgi/
Basic_Coding_Style
skeletonz-coding.txt,0.6,,http://orangoo.com/skeletonz/Developer_guide/
Coding_convention/
software-carpentry.txt,0.1,,http://www.swc.scipy.org/lec/style.html
zope.txt,0.0,,http://wiki.zope.org/zope3/CodingStyle
Martin Vilcans
> 2008/1/7, MartinR...@gmail.com <MartinR...@gmail.com>:
> > Anything written somewhere that's thorough? Any code body that should
> > serve as a reference?
>
> http://www.python.org/dev/peps/pep-0008/
The problem with PEP 8 is that even code in the standard libraries
doesn't follow the recommendations regarding the naming of functions
for example. The recommendation is to_separate_words_with_underscore,
but some code uses lowerCamelCase instead.
I tended to dislike the underscore convention, but after forcing
myself to use it for a while I'm starting to appreciate its beauty.
Colin J. Williams
> On 1/7/08, Guilherme Polo <ggp...@gmail.com> wrote:
>> 2008/1/7, MartinR...@gmail.com <MartinR...@gmail.com>:
>>> serve as a reference?
>> http://www.python.org/dev/peps/pep-0008/
>
> The problem with PEP 8 is that even code in the standard libraries
> doesn't follow the recommendations regarding the naming of functions
> for example. The recommendation is to_separate_words_with_underscore,
> but some code uses lowerCamelCase instead.
>
> I tended to dislike the underscore convention, but after forcing
> myself to use it for a while I'm starting to appreciate its beauty.
I've come to like lowerCamelCase and a
tab of 2.
A tab of 4 wastes more space than is
needed for the occasional heavy
indenting.
Colin W.
Neil Cerutti
> On 1/7/08, Guilherme Polo <ggp...@gmail.com> wrote:
> > 2008/1/7, MartinR...@gmail.com <MartinR...@gmail.com>:
> > > serve as a reference?
> >
> > http://www.python.org/dev/peps/pep-0008/
>
> The problem with PEP 8 is that even code in the standard libraries
> doesn't follow the recommendations regarding the naming of functions
> for example. The recommendation is to_separate_words_with_underscore,
> but some code uses lowerCamelCase instead.
>
> I tended to dislike the underscore convention, but after forcing
> myself to use it for a while I'm starting to appreciate its beauty.
Conventions get broken when there's a good reason, e.g., elegant
looking "deque" instead of clumsy looking "Deque".
--
Neil Cerutti <mr.cerut...@gmail.com>
Matthew Woodcraft
> While not required by any means, you will also find it handy to follow
> *every* entry in the list with a comma, even the last one in the list
> (this is legal Python). That is, in your example:
>
> 'too long',
> 'too long too',
> 'too long too',
> 'last item',
> ]
>
> Later on when you want to reorder the items, then you can just copy/
> paste whole lines, even if moving to or from the bottom of the list.
> This is also a good argument for putting the closing ']' on its own
> line, instead of on the same line as the last item.
The other good reason for doing these two things is that they fit
better with the line-based rules that most source code management
systems use for merging.
-M-
Matthew Woodcraft
> A quick look (thorough analysis still required) shows that OLPC and
> PyPy are, indeed, extensive standards.
> one-laptop-per-child.html (olpc),74.3,,http://wiki.laptop.org/go/Python_Style_Guide
I think that's mostly PEP 8, with some notes added.
-M-
MartinR...@gmail.com
Matthew Woodcraft wrote:
> I think [the olpc guidlines are] mostly PEP 8, with some notes added.
Took a good look. You are absolutely correct.
PEP 8 is basically word processing text stuck between <pre> and </pre>
tags. OLPC is Wiki HTML. Good example of how the latter is a lot
bigger than the former, with little extra content.
Caleb
> Anything written somewhere that's thorough? Any code body that should
> serve as a reference?
1. Don't use tabs (use spaces).
2. Study "import this"
3. Use lists and dictionaries as much as you possibly can
4. Use comprehensions and generators as much as you possibly can
5. Use the standard library for everything you possibly can
6. As much as you possibly can, when starting a new project, postpone
setting up classes for everything (start with functions). In some
projects, you might never need the overhead at all.
It will be difficult to go far wrong regarding style if you do a lot of
what's in this list. This list is not mine. I jotted these points
down, but this information is continually repeated by the actual wise
people (not me) in this newsgroup.
Caleb
rui
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
Rui
http://rui.tumblr.com
"Rubi? Aquela novela do SBT?"
~ Carla Perez sobre Ruby
"Em Python, tudo é objeto, além de lindo e maravilhoso."
~ Caetano Veloso sobre Python