[Types-sig] Re: Revive the types sig?
Sun, 11 Mar 2001 22:27:16 -0800
(followed-up to types-sig)
Jeremy Hylton wrote:
> >>>>> "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
I've seen hundreds of examples but here's one that I produced in 30
seconds in the interpreter:
>>> a = None
>>> # 10,000 lines of code
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "c:\python20\lib\urllib.py", line 61, in urlopen
File "c:\python20\lib\urllib.py", line 139, in open
fullurl = unwrap(fullurl)
File "c:\python20\lib\urllib.py", line 857, in unwrap
url = string.strip(url)
File "c:\python20\lib\string.py", line 80, in strip
AttributeError: 'None' object has no attribute 'strip'
The interpreter should have caught the problem in the urlopen, not
several calls down. Also, it would be nice if a type checker or IDE
could detect a potential problem by inspecting the assignments to "a"
and the declaration of urlopen. Of course Python is a dynamic language
so you can't always depend on that but sometimes it would work.
> 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.
The first two priorities are err and doc. There are two other lesser
goals: "opt" (through type inference) and "idl" which is about
integrating Python with strongly-type systems such as SOAP, .NET, COM,
CORBA and all of the statically typed programming languages. e.g. for
Jython it would be great if you could generate strongly typed Java
classes if you wanted to.
Programming the way
- (originated with Skip Montanaro?)