[Types-sig] Proposed Goals PEP

[Paul Prescod]

"Krishnaswami, Neel" wrote:
> 
>...
> type is never wrong.
> 
> Eg (with bogus example syntax):
> 
>   >>> d :: {Int: String} = {3: "foo", 4: "bar"}
>   >>> d[17] = 42
>   TypeError: d is of type {Int: String}, assigned an integer.

I'd rather not bring in declarations of object types. People are going
to confuse that with declarations of VARIABLE types (which they will
confuse with declarations of PARAMATER types). 

Plus, we are going to get flamed for changing the language for a
performance optimization. 

Finally, the whole system gets weird when you start subtyping. We would
need to do a potentially expensive issubclass on each insert and then,
when you pass the object to a function, if the function's types do not
exactly line up with yours, your performance goes all to hell because it
may need to do the whole thing again.

In general, I still think parametric type checking is something I want
to defer. I like the fact that the executable types proposal grows
naturally into those kinds of type checking without requiring US to
specify them as part of standard Python. If you want to write code that
is paranoid and slow, you can do it but average Python programmers would
not accidently change the whole runtime behavior of their program by
adding a few declarations.

And how does a list of tuples of a list of tuples work? I have to
generate strongly typed objects at every level? I think the costs are
outweighing the benefits...maybe StringSequence is such a common case
that we should have a special type for it.

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