>>>>> "PP" == Paul Prescod <paulp@ActiveState.com> writes:
PP> Let's discuss my proposal in the types-sig. Executive summary:
PP> * incremental development policy
PP> * syntax for parameter type declarations
PP> * syntax for return type declarations
PP> * optional runtime type checking
PP> * goals are better runtime error reporting and method
PP> documentation
If your goal is really the last one, then I don't see why we need the
first four <0.9 wink>. Let's take this to the doc-sig.
I have never felt that Python's runtime error reporting is all that
bad. Can you provide some more motivation for this concern? Do you
have any examples of obscure errors that will be made clearer via type
declarations?
The best example I can think of for bad runtime error reporting is a
function that expects a sequence (perhaps of strings) and is passed a
string. Since a string is a sequence, the argument is treated as a
sequence of length-1 strings. I'm not sure how type declarations
help, because:
(1) You would usually want to say that the function accepts a
sequence -- and that doesn't get you any farther.
(2) You would often want to say that the type of the elements of
the sequence doesn't matter -- like len -- or that the type of
the elements matters but the function is polymorphic -- like
min. In either case, you seem to be ruling out types for
these very common sorts of functions.
If documentation is really the problem you want to solve, I imagine
we'd make much more progress if we could agree on a javadoc-style
format for documentation. The ability to add return-type declarations
to functions and methods doesn't seem like much of a win.
Jeremy
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4