On 2 October 2013 00:45, Rotwang <sg...@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 -- https://mail.python.org/mailman/listinfo/python-list