Gregory Ewing <greg.ew...@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*
> reader.
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
purpose.
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
frobnication.
:return: A new list of processed Splet instances.
The flang is frobnicated according to the Weebly-Ruckford
algorithm.
"""
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 |
Ben Finney
--
https://mail.python.org/mailman/listinfo/python-list
