$ sudo apt-get install vsftpd
config @ /etc/vsftpd.conf
$ sudo service vsftp start
$ sudo service vsftp stop
Wednesday, August 26, 2015
Saturday, August 15, 2015
Saturday, August 8, 2015
Friday, August 7, 2015
python -m SimpleHTTPServer
to serve up the current folder via HTTP server
$ python -m SimpleHTTPServer
Wednesday, August 5, 2015
debian / ubuntu - installing security updates from the command line
$ sudo apt-get install unattended-upgrades
$ sudo unattended-upgrade
askubuntu - How can I install just security updates from the command line ?
$ sudo unattended-upgrade
askubuntu - How can I install just security updates from the command line ?
Sunday, August 2, 2015
python docstring conventions - PEP 0257
PEP 0257 - Docstring Conventions:
>>>
One-line Docstrings
One-liners are for really obvious cases. They should really fit on
one line. For example:
def kos_root(): """Return the pathname of the KOS root directory.""" global _kos_root if _kos_root: return _kos_root ...Notes:
-
Triple quotes are used even though the string fits on one line. This makes it easy to later expand it.
-
The closing quotes are on the same line as the opening quotes. This looks better for one-liners.
-
There's no blank line either before or after the docstring.
-
The docstring is a phrase ending in a period. It prescribes the function or method's effect as a command ("Do this", "Return that"), not as a description; e.g. don't write "Returns the pathname ...".
-
The one-line docstring should NOT be a "signature" reiterating the function/method parameters (which can be obtained by introspection).Don't do:
def function(a, b): """function(a, b) -> list"""
This type of docstring is only appropriate for C functions (such as built-ins), where introspection is not possible. However, the nature of the return value cannot be determined by introspection, so it should be mentioned. The preferred form for such a docstring would be something like:
def function(a, b): """Do X and return a list."""
Multi-line Docstrings
Multi-line docstrings consist of a summary line just like a one-line
docstring, followed by a blank line, followed by a more elaborate
description. The summary line may be used by automatic indexing
tools; it is important that it fits on one line and is separated from
the rest of the docstring by a blank line. The summary line may be on
the same line as the opening quotes or on the next line. The entire
docstring is indented the same as the quotes at its first line (see
example below).
Insert a blank line after all docstrings (one-line or multi-line) that
document a class -- generally speaking, the class's methods are
separated from each other by a single blank line, and the docstring
needs to be offset from the first method by a blank line.
The docstring of a script (a stand-alone program) should be usable as
its "usage" message, printed when the script is invoked with incorrect
or missing arguments (or perhaps with a "-h" option, for "help").
Such a docstring should document the script's function and command
line syntax, environment variables, and files. Usage messages can be
fairly elaborate (several screens full) and should be sufficient for a
new user to use the command properly, as well as a complete quick
reference to all options and arguments for the sophisticated user.
The docstring for a module should generally list the classes,
exceptions and functions (and any other objects) that are exported by
the module, with a one-line summary of each. (These summaries
generally give less detail than the summary line in the object's
docstring.) The docstring for a package (i.e., the docstring of the
package's
__init__.py
module) should also list the modules and
subpackages exported by the package.
The docstring for a function or method should summarize its behavior
and document its arguments, return value(s), side effects, exceptions
raised, and restrictions on when it can be called (all if applicable).
Optional arguments should be indicated. It should be documented
whether keyword arguments are part of the interface.
The docstring for a class should summarize its behavior and list the
public methods and instance variables. If the class is intended to be
subclassed, and has an additional interface for subclasses, this
interface should be listed separately (in the docstring). The class
constructor should be documented in the docstring for its
__init__
method. Individual methods should be documented by their own
docstring.
If a class subclasses another class and its behavior is mostly
inherited from that class, its docstring should mention this and
summarize the differences. Use the verb "override" to indicate that a
subclass method replaces a superclass method and does not call the
superclass method; use the verb "extend" to indicate that a subclass
method calls the superclass method (in addition to its own behavior).
Do not
use the Emacs convention of mentioning the arguments of
functions or methods in upper case in running text. Python is case
sensitive and the argument names can be used for keyword arguments, so
the docstring should document the correct argument names. It is best
to list each argument on a separate line.
For example:
def complex(real=0.0, imag=0.0): """Form a complex number. Keyword arguments: real -- the real part (default 0.0) imag -- the imaginary part (default 0.0) """ if imag == 0.0 and real == 0.0: return complex_zero ...
Unless the entire docstring fits on a line, place the closing quotes
on a line by themselves. This way, Emacs'
fill-paragraph
command
can be used on it
<<<
Subscribe to:
Posts (Atom)