python function parameters, debugging, comments, etc.

[Oscar Benjamin]

On 2 October 2013 00:45, Rotwang <sg552 at hotmail.co.uk> wrote:
>
> So the upside of duck-typing is clear. But as you've already discovered, so
> is the downside: Python's dynamic nature means that there's no way for the
> interpreter to know what kind of arguments a function will accept, and so a
> user of any function relies on the function having clear documentation.

It is still necessary to document the arguments of functions in
explicitly typed languages. Knowing that you need a list of strings
does not mean that you know what the function expects of the values of
the strings and what it will try to do with them.

When you see something like
    int atoi (const char * str);
you know that it takes a string and returns an integer. However the
function name does not clearly indicate any purpose. What kind of
string should I pass in? Is the returned value an error code or a
value generated from the string (it's actually both). Even if you know
that the function parses strings representing integers there are still
many different formats for representing numbers as strings. Should the
string be in a locale-dependent format? What kind of text encoding is
it using (utf-8 maybe)? Should the characters represent an integer in
decimal format or hex, octal, binary or something else?

Inspecting types can be a quick way to gain information about the
meaning of arguments and return values but it is not something that
you should be relying on to replace documentation.


Oscar