Mercurial > pylearn
comparison doc/v2_planning/coding_style.txt @ 1304:ca7e4829f6a0
Merged
author | Olivier Delalleau <delallea@iro> |
---|---|
date | Fri, 01 Oct 2010 14:56:54 -0400 |
parents | a8f909502886 cc1c5720eeca |
children | ef0f3deead94 |
comparison
equal
deleted
inserted
replaced
1303:b5673b32e8ec | 1304:ca7e4829f6a0 |
---|---|
243 How do we write docs? | 243 How do we write docs? |
244 | 244 |
245 Ideas (DE): | 245 Ideas (DE): |
246 | 246 |
247 * Most major Python projects suggest following PEP-257: | 247 * Most major Python projects suggest following PEP-257: |
248 http://www.python.org/dev/peps/pep-0257/, which contains conventions on | 248 http://www.python.org/dev/peps/pep-0257/, which contains conventions on |
249 writing docstrings (what they should contain, not the specific markup) for | 249 writing docstrings (what they should contain, not the specific markup) |
250 Python. These are very general conventions, however,. | 250 for Python. These are very general conventions, however,. |
251 | 251 |
252 * Numpy, in particular, has a very nice page on how to document things if | 252 * Numpy, in particular, has a very nice page on how to document things if |
253 contributing: http://projects.scipy.org/numpy/wiki/CodingStyleGuidelines | 253 contributing: http://projects.scipy.org/numpy/wiki/CodingStyleGuidelines |
254 (it's mostly about documentation, not coding style, despite the page name). | 254 (it's mostly about documentation, not coding style, despite the page |
255 name). | |
255 | 256 |
256 * A pretty good example from numpy, with relevant comments: | 257 * A pretty good example from numpy, with relevant comments: |
257 http://github.com/numpy/numpy/blob/master/doc/example.py | 258 http://github.com/numpy/numpy/blob/master/doc/example.py |
258 | 259 |
259 * A real-life example (record arrays) from numpy: | 260 * A real-life example (record arrays) from numpy: |
260 http://github.com/numpy/numpy/blob/master/numpy/core/records.py | 261 http://github.com/numpy/numpy/blob/master/numpy/core/records.py |
261 | 262 |
262 * The recommendations are quite sane and common-sense, we should follow them. | 263 * The recommendations are quite sane and common-sense, we should follow them. |
263 | 264 |
264 * Make sure that what we write is compatible with tools like sphinx's autodoc | 265 * numpy's way of doing things is a bit different from the way we currently |
265 extension: http://sphinx.pocoo.org/ext/autodoc.html#module-sphinx.ext.autodoc (which we | 266 document Theano: they don't use param/type/rtype, for instance, but nice |
266 will most probably use to generate semi-automatic pretty docs) | 267 readable section titles. I personally find their approach better-looking |
268 and they do have a sphinx extension that would allow us to have the same | |
269 style | |
270 (http://github.com/numpy/numpy/blob/master/doc/sphinxext/numpydoc.py). | |
271 The disadvantage of taking this approach is that Theano and Pylearn will | |
272 be documented slightly differently | |
273 | |
274 * Make sure that what we write is compatible with tools like sphinx's | |
275 autodoc extension: | |
276 http://sphinx.pocoo.org/ext/autodoc.html#module-sphinx.ext.autodoc (which | |
277 we will most probably use to generate semi-automatic pretty docs) | |
267 | 278 |
268 * Nice cheat-sheet for docutils: | 279 * Nice cheat-sheet for docutils: |
269 http://docutils.sourceforge.net/docs/user/rst/quickref.html | 280 http://docutils.sourceforge.net/docs/user/rst/quickref.html |
270 | 281 |
271 * http://docs.python.org/release/2.5.2/lib/module-doctest.html - | 282 * http://docs.python.org/release/2.5.2/lib/module-doctest.html - |
272 in-documentation unit-testing: we should perhaps encourage people to write | 283 in-documentation unit-testing: we should perhaps encourage people to |
273 such things where warranted (where there are interesting usage examples). | 284 write such things where warranted (where there are interesting usage |
274 notetests can automatically run those, so no configuration overhead is | 285 examples). notetests can automatically run those, so no configuration |
275 necessary. | 286 overhead is necessary. |
276 | 287 |
277 Compatibility with various Python versions | 288 Compatibility with various Python versions |
278 ------------------------------------------ | 289 ------------------------------------------ |
279 | 290 |
280 * Which Python 2.x version do we want to support? | 291 * Which Python 2.x version do we want to support? |