[Types-sig] Re: Revive the types sig?

[Paul Prescod]

(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
> declarations?

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
...
>>> urllib.urlopen(a)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "c:\python20\lib\urllib.py", line 61, in urlopen
    return _urlopener.open(url)
  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
    return s.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.

-- 
Python:
    Programming the way
    Guido
    indented it.
       - (originated with Skip Montanaro?)