On Sat, 22 Apr 2006 06:39 pm, Guido van Rossum wrote: ... > > No. This is the kind of thing that would very quickly turn "optional" > typing into *mandatory* typing. One library package adds type > declarations. Now all packages that use it are required to either add > type declarations or explicit conversions or checks. The cost of > repeated explicit conversions/checks strongly suggests that adding > type declaration is the better choice -- and now you have a ripple > effect (similar to the way 'const' declarations, once added, cascade > in C or C++ code). Soon enough the entire library uses type > declarations and now all user code is faced with the same choice. All > style guides will strongly suggest type declarations. And we end up > with Java without curly braces. recapping:
What exactly is list[int]? - list[int] is shorthand for type(list[0]) <: int and type(list[1]) <: int and type(list[2]) <: int ... where "t1 <: t2" means t1 is a structural subtype of t2 otherwise stated as: for any natural number n, list[n] <: int which is essentially an un-typed viewpoint. So we add the type variable to the runtime object. Luca Cardelli's paper on the typed lambda calculus has a lot to say about adding types (http://research.microsoft.com/Users/luca/Papers/OnUnderstanding.A4.pdf) If I understand the math right, we can expressed this as a bounded universal quantifier? all[a <: int] list[a] You would have to construct it specifically with the type attribute: var = list[int] # py3k var[0] = 42 # OK var[1] = "foo" # run-time type error Java arrays work this way. quote "More formally: an assignment to an element of an array whose type is A[], where A is a reference type, is checked at run-time to ensure that the value assigned can be assigned to the actual element type of the array, where the actual element type may be any reference type that is assignable to A." see (http://java.sun.com/docs/books/jls/second_edition/html/arrays.doc.html) The implications of this for the programmer are that type errors would be found closer to the source. But, as was pointed out there will be a proliferation of listOf(T) constructors. And a proliferation of performance soaks. so... In my experience deep type checking at runtime is really useful, common, but rarely called type checking. Normally we to write it manually (and call it "input validation" or "checking preconditions"). Usually on major system boundaries. Especially in distributed systems. I would be happy to pay the cost of run-time type checking if I could invoke it explicitly. Then I could choose where the performance hit happens and how often. But how can dynamic type checks be made obvious and explicit syntactically? Maybe with an annotation: @enforce_types def func(x: t1, y: t2) -> t3: ...body... or with an explicit check: def func(x, y) : if not x, y <: t1, t2: throw "mate, you have a type error" Perhaps we could limit type definitions to interfaces only, and allow preconditions and postconditions there. This would be simple to grasp. If you implement an interface, you'll be paying the cost of runtime type checks. After all the whole point of interfaces in Python is to enforce compliance with a standard. Remember this is not Java, we already have multiple inheritance. _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com