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

[Guido van Rossum]

[Paul]
> > Even if we took an extreme position and ONLY allowed type annotations
> > for basic types like strings, numbers and sequences, Python would
> > still be a better language.

[Marcin 'Qrczak' Kowalczyk]
> I strongly disagree with making it broken-as-designed. A flawed type
> system adds too much complexity and yields pain in fighting with its
> limitations compared to benefits. We should either do it such that
> it really works in most cases, or don't do it at all.
> 
> When you pass a string instead of a number to a function, the error
> is often caught immediately as soon as the parameter is used. But when
> you pass a list and some of its elements don't have the expected type,
> the error is more subtle.
> 
> For me the ability to specify the type of an argument, but inability to
> say anything about elements of a list or tuple, makes the system not
> worth adding to a language. Similarly, being able to tell something
> only about builtin types or interfaces.
> 
> > Java also does not yet have parameterized types and yet it is the
> > most rapidly growing statically typed programming language!
> 
> Many complaints about static typing result from the assumption that
> it must be as poor as in Java, or as complex as in C++.
> 
> I suggest taking Haskell, ML or Eiffel as inspiration, not Java.
> Java requires type casts to overcome limitations of the static type
> system, because of lack of genericity (besides builtin array hack)
> and lack of the ability to form conjunctions of interfaces.
> 
> Even Java is going to add genericity, and there already exist Java
> extensions which do it. Lack of genericity is IMHO the biggest single
> flaw in Java's type system.
> 
> > Deferred for future versions (or never):
> > 
> >  * compile-time type checking
> >  * parameterized types
> >  * declarations for variables and attributes
> 
> I'm afraid that it would give python the worst parts of static and
> dynamic typing.
> 
> I agree that Python's typing should be optional, but disagree with
> the rest of your goals :-(

Marcin,

Your comments ask for a "classic" type system as found in other
statically typed languages.  You're giving all the right examples.

Paul has made it clear that he's given up on that, and wants to do
something else.  Given that we've tried to come up with a classic type
system twice before and failed, I have to agree with the process here:
let's try something completely different.  Let it be a spectacular
success or a valiant failure, but let's not bang our heads against the
same wall for the third time.

Clearly you and Paul don't agree on what the goal is.  I suggest that
rather than wasting your time by arguing with Paul, you should go off
and propose your own PEP, that furthers *your* goals.  You can do that
in the same types-SIG -- the charter is wide enough.  Just make it
clear that you are barking up a different tree.  I expect that Jeremy
Hylton will support your efforts, and who knows who else.

There's nothing wrong with writing two PEPs to choose from!  It makes
a lot more sense to me than trying to unify into one proposal what are
clearly very different goals.

--Guido van Rossum (home page: http://www.python.org/~guido/)