Guido van Rossum wrote: > This seems a good idea to remember when we get to that point. > > But let me point out that the key concern I have about the expense of > type checking is what would be done when unchecked code calls a > function with type-checked arguments. 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], then I don't see how we can prevent the cost of doing a > million checks to ensure that each and every item in the list is an > int; either we do it all at once at the call site, or we amortize the > cost over the lifetime of every list object, whether or not it is ever > going to be used in a typechecked call. Neither sounds very > attractive, and AFAICT your approach doesn't solve this particular > issue.
If you do the check early for intness (or lazily with a wrapper), that would hopefully mean that an optimizer could use that information to avoid later type checks, e.g., by inlining code. Though that implies that you are checking for concrete types, not interfaces. Anyway, you have to do a type test at some point when you use an object; if it is done earlier that shouldn't mean more work ultimately (unless you are ignoring lots of objects). Lazy testing for sequences makes some sense, because in the case of an iterator (and maybe even an iterable, which may not be finite) you can only ever do lazy testing. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
