SUBMITTING_PYTHON 3.2 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110
  1. $Date$
  2. NOTE: Please improve this list!
  3. Dear (new) GRASS Developer,
  4. When submitting Python code to GRASS SVN repository, please take
  5. care of following rules:
  6. [ see SUBMITTING for C hints ]
  7. [ see SUBMITTING_SCRIPTS for shell script hints ]
  8. [ see SUBMITTING_TCLTK for tcl and tk hints ]
  9. [ see SUBMITTING_DOCS for documentation ]
  10. 1. Indentation
  11. As Python determines nesting based upon indentation, it
  12. isn't just a stylistic issue.
  13. Please use 4-space indentation (GNU Emacs python-mode default).
  14. See also "Python Style Guide" by Guido van Rossum
  15. http://www.python.org/doc/essays/styleguide.html
  16. 2. Add a header section to the script you submit and make sure you
  17. include the copyright. The purpose section is meant to contain a
  18. general over view of the code in the file to assist other
  19. programmers that will need to make changes to your code. For this
  20. purpose use Python Docstring, see
  21. http://epydoc.sourceforge.net/docstrings.html
  22. Example (fictitious header for a script called r.myscript):
  23. """
  24. MODULE: r.myscript
  25. AUTHOR(S): Me <email AT some domain>
  26. PURPOSE: Calculates univariate statistics from a GRASS raster map
  27. COPYRIGHT: (C) 2007 by the GRASS Development Team
  28. This program is free software under the GNU General Public
  29. License (>=v2). Read the file COPYING that comes with GRASS
  30. for details.
  31. """
  32. The copyright protects your rights according to GNU General Public
  33. License (www.gnu.org).
  34. 3. - deleted.
  35. We don't want the $ ID $ in source code any more as it causes problems
  36. for the branches.
  37. 4. PLEASE take the time to add comments throughout your code explaining what
  38. the code is doing. It will save a HUGE amount of time and frustration for
  39. other programmers that may have to change your code in the future.
  40. 5. Make sure a new line is at the end of each file.
  41. 6. For consistency, use README rather than README.txt for any README files.
  42. 7. Be sure to develop on top of the LATEST GRASS code (which is in SVN repository).
  43. You can re-check before submission with 'svn diff':
  44. Be sure to create unified ("diff -u") format. "Plain" diffs (the default
  45. format) are risky, because they will apply without warning to code which
  46. has been substantially changed; they are also harder to read than unified.
  47. Such diffs should be made from the top-level directory, e.g.
  48. "svn diff gui/wxpython/wxgui.py"; that way, the diff will
  49. include the pathname rather than just "wxgui.py".
  50. 8. When submitting new files to the repository set SVN properties,
  51. usually for directory
  52. svn:ignore : *.pyc
  53. or e.g. for Python file
  54. svn:mime-type : text/python
  55. svn:keywords : Author Date Id
  56. svn:eol-style : native
  57. See
  58. http://svnbook.red-bean.com/en/1.4/svn.advanced.props.html
  59. 8. Tell the other developers about the new code using the following e-mail:
  60. grass-dev@lists.osgeo.org
  61. To subscribe to this mailing list, see
  62. http://lists.osgeo.org/mailman/listinfo/grass-dev
  63. 9. In case of questions feel free to contact the developers at the above
  64. mailing list.
  65. http://www.grass-gis.org/devel/index.php#submission
  66. ...
  67. [please add further hints if required]