> Guido van Rossum wrote: > If I have some utterly dynamic > code that comes up with a list of a million ints, and then I pass > that > as an argument to a function that requests the argument type is > list[int], > > you wrap it in something that checks elements for intness > as you access them. [...]
Yes you are right. I see some sub-cases. If the value structure is immutable, then as it is constructed you could calculate the Godel strings bottom-up. Even this effectively doubles the work of the runtime since it has to calculate the value _and_ the type information. All this additional calculation just in case a type check might be needed. So not good. And this is the best case. If the data structure is mutable like list[int] then then attempting to keep the Godel strings up-to-date means re-calculating the entire string every time an element changes, again just in case a type check is needed. Last case, what about recursive types? Chances are an algorithm needs to keep track of nodes visited, further adding to the workload. The "Lingua Franca IDL" distributed system was happy to bear this runtime load because of the large-grained method calls over a network. (http://citeseer.ist.psu.edu/27902.html) However within the same executable the costs will be too high. So yes, this idea doesn't tackle the hard problem of the cost of run-time type checking of dynamic data. Is this intractable? I don't see how it can be lightened up unless 'nominal subtyping' aka 'inheritance subtyping' is used. But that is not Pythonic since we want duck typing or 'structural subtyping'. _______________________________________________ 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
