ben+python at benfinney.id.au
Mon Mar 3 23:31:48 CET 2014
Gregory Ewing <greg.ewing at canterbury.ac.nz> writes:
> Just because the compiler *can* infer the return type doesn't
> necessarily mean it *should*. When I was playing around with
> functional languages, I ended up adopting the practice of always
> declaring the types of my functions, because it helps the *human*
Sure. In a duck-typed language like Python, it is still helpful to the
human reader to document the *meaning* of each parameter, beyond what is
indicated by the name. We have reStructuredText and docstrings for this
def frobnicate(flang, splets, queeble=False):
""" Righteously frobnicate the flang.
:param flang: A file-like object, opened for reading.
:param splets: A sequence of unprocessed Splet instances.
:param queeble: If ``True``, re-vitrify the flang during
:return: A new list of processed Splet instances.
The flang is frobnicated according to the Weebly-Ruckford
for line in flang:
> (It also helped the compiler produce comprehensible error messages in
> the event of a type error.)
Docstrings in the above reStructuredText field-list style will be
processed by Epydoc <URL:http://epydoc.sourceforge.net/fields.html>.
Other styles of specifying parameters in an mechanically-extractable
form are also used, by Sphinx for example. The point is, we have
docstrings, and conventions in docstrings for specifying parameters for
the human reader *and* for automated tools to read.
\ “… Nature … is seen to do all things Herself and through |
`\ herself of own accord, rid of all gods.” —Titus Lucretius |
_o__) Carus, c. 40 BCE |
More information about the Python-list