Merge branch 'master' into dan_stateless

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 :