On 4/22/06, Talin <[EMAIL PROTECTED]> wrote: > Greg Ewing <greg.ewing <at> canterbury.ac.nz> writes: > > > Giovanni Bajo wrote: > > > > > Another (similar) way would be to let the user pay for the high > > > typechecking > > > price in normal cases *but* provide a list[int] class, which is a list > > > decorated with typechecks on modification operations. We could have > > > list[int|float]() to construct a list which can hold either ints or > > > floats. > > > > This is worth thinking about. Recently when pondering the > > question of when it would or would not be appropriate to > > put in type assertions to help catch bugs, I concluded > > that it makes the most sense to do so when building a > > data structure, but not when just passing things around > > between calls. > > This makes total sense to me. You don't check the type of each > entry of the list - you check the type of the list itself. This is > pretty much the way statically typed languages work. > > This means that you can't pass a regular list to a function > that expects a "list of ints". So its an extra step to convert > the list to the proper type. As long as the syntax isn't too > hard to type, that shouldn't be a problem, and this way the > user knows that they are paying the cost for the conversion. > "Explicit is better than implicit".
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. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ 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
