summaryrefslogtreecommitdiffstats
path: root/external_libs/python/python-daemon-2.0.5/doc/hacking.txt
diff options
context:
space:
mode:
authorHanoh Haim <hhaim@cisco.com>2015-08-26 15:33:20 +0300
committerHanoh Haim <hhaim@cisco.com>2015-08-26 15:33:20 +0300
commitf15923902c4259978b952ed4b6aef2db4c9f430b (patch)
tree27e26627964bab4bd020e696a6d6f71d77515d04 /external_libs/python/python-daemon-2.0.5/doc/hacking.txt
parentfc46f2618332037a8c1b58fbce5d616033bff1c9 (diff)
remove old python
Diffstat (limited to 'external_libs/python/python-daemon-2.0.5/doc/hacking.txt')
-rw-r--r--external_libs/python/python-daemon-2.0.5/doc/hacking.txt180
1 files changed, 0 insertions, 180 deletions
diff --git a/external_libs/python/python-daemon-2.0.5/doc/hacking.txt b/external_libs/python/python-daemon-2.0.5/doc/hacking.txt
deleted file mode 100644
index 9484dbd0..00000000
--- a/external_libs/python/python-daemon-2.0.5/doc/hacking.txt
+++ /dev/null
@@ -1,180 +0,0 @@
-Developer's guide
-#################
-
-:Author: Ben Finney <ben+python@benfinney.id.au>
-:Updated: 2014-11-28
-
-
-Project layout
-==============
-
-::
-
- ./ Top level of source tree
- doc/ Project documentation
- bin/ Executable programs
- daemon/ Main ‘daemon’ library
- test/ Unit tests
-
-
-Code style
-==========
-
-Python
-------
-
-All Python code should conform to the guidelines in PEP8_. In
-particular:
-
-* Indent each level using 4 spaces (``U+0020 SPACE``), and no TABs
- (``U+0008 CHARACTER TABULATION``).
-
-* Name modules in lower case, ``multiplewordslikethis``.
-
-* Name classes in title case, ``MultipleWordsLikeThis``.
-
-* Name functions, instances and other variables in lower case,
- ``multiple_words_like_this``.
-
-* Every module, class, and function has a Python doc string explaining
- its purpose and API.
-
- *Exception*: Functions whose purpose and API are mandated by Python
- itself (dunder-named methods) do not need a doc string.
-
-* Doc strings are written as triple-quoted strings.
-
- * The text of the doc string is marked up with reStructuredText.
-
- * The first line is a one-line synopsis of the object. This summary
- line appears on the same line as the opening triple-quote,
- separated by a single space.
-
- * Further lines, if needed, are separated from the first by one
- blank line.
-
- * The synopsis is separated by one space from the opening
- triple-quote; this causes it to appear four columns past the
- beginning of the line. All subsequent lines are indented at least
- four columns also.
-
- * The synopsis is followed by a reStructuredText field list. The
- field names are: “param foo” for each parameter (where “foo” is
- the parameter name), and “return” for the return value. The field
- values describe the purpose of each.
-
- * The closing triple-quote appears on a separate line.
-
- Example::
-
- def frobnicate(spam, algorithm="dv"):
- """ Perform frobnication on ``spam``.
-
- :param spam: A travortionate (as a sequence of strings).
- :param algorithm: The name of the algorithm to use for
- frobnicating the travortionate.
- :return: The frobnicated travortionate, if it is
- non-empty; otherwise None.
-
- The frobnication is done by the Dietzel-Venkman algorithm,
- and optimises for the case where ``spam`` is freebled and
- agglutinative.
-
- """
- spagnify(spam)
- # …
-
-* All ``import`` statements appear at the top of the module.
-
-* Each ``import`` statement imports a single module, or multiple names
- from a single module.
-
- Example::
-
- import sys
- import os
- from spam import foo, bar, baz
-
-.. _PEP8: http://www.python.org/dev/peps/pep-0008/
-
-Additional style guidelines:
-
-* All text files (including program code) are encoded in UTF-8.
-
-* A page break (``U+000C FORM FEED``) whitespace character is used
- within a module to break up semantically separate areas of the
- module.
-
-* Editor hints for Emacs and Vim appear in a comment block at the
- file's end::
-
-
- # Local variables:
- # coding: utf-8
- # mode: python
- # End:
- # vim: fileencoding=utf-8 filetype=python :
-
-
-Unit tests
-==========
-
-All code should aim for 100% coverage by unit tests. New code, or
-changes to existing code, will only be considered for inclusion in the
-development tree when accompanied by corresponding additions or
-changes to the unit tests.
-
-Test-driven development
------------------------
-
-Where possible, practice test-driven development to implement program
-code.
-
-* During a development session, maintain a separate window or terminal
- with the unit test suite for the project running continuously, or
- automatically every few seconds.
-
-* Any time a test is failing, the only valid change is to make all
- tests pass.
-
-* Develop new interface features (changes to the program unit's
- behaviour) only when all current tests pass.
-
-* Refactor as needed, but only when all tests pass.
-
- * Refactoring is any change to the code which does not alter its
- interface or expected behaviour, such as performance
- optimisations, readability improvements, modularisation
- improvements etc.
-
-* Develop new or changed program behaviour by:
-
- * *First* write a single, specific test case for that new behaviour,
- then watch the test fail in the absence of the desired behaviour.
-
- * Implement the minimum necessary change to satisfy the failing
- test. Continue until all tests pass again, then stop making
- functional changes.
-
- * Once all tests (including the new test) pass, consider refactoring
- the code and the tests immediately, then ensure all the tests pass
- again after any changes.
-
- * Iterate for each incremental change in interface or behaviour.
-
-Test-driven development is not absolutely necessary, but is the
-simplest, most direct way to generate the kind of program changes
-accompanied by unit tests that are necessary for inclusion in the
-project.
-
-
-..
- Local variables:
- coding: utf-8
- mode: rst
- time-stamp-format: "%:y-%02m-%02d"
- time-stamp-start: "^:Updated:[ ]+"
- time-stamp-end: "$"
- time-stamp-line-limit: 20
- End:
- vim: fileencoding=utf-8 filetype=rst :