At 01:08 AM 7/20/2006 -0700, Talin <[EMAIL PROTECTED]> wrote: >In addition, one of the key design points is that these annotations >would have no fixed meaning, but would instead simply be objects that >are interpreted in various contexts, including function decorators for >which the annotations might have special meaning.
Actually, you've left out an important bit: the __typecheck__ function. Guido's original proposal called for __typecheck__(arg, type) to be called on each argument that has a type declaration, with the result replacing the argument value. The builtin __typecheck__ function would be a no-op, but you could change its meaning within a module. Given this definition for the semantics, none of the issues you raised are relevant. >I'm going to go out on a limb here and say that both of these concepts >are less useful than one would think, and are likely to create a host of >problems. I suspect that the proposed design will lead to difficulty of >interpretation, and conflicts between different but overlapping goals >within the design of a program. I think you're worrying too much. I've written decorators that create signature-specific wrapper functions by exec'ing a string to create the wrapping function. It's a bit tricky, but you might be able to create a helper library to make it easier. There are some annoyances, too, like not being able to have the line numbers make sense in the decorator itself. But, if Guido's __typecheck__ idea is in effect, none of that would be necessary in order to support type checking. Also, for overloaded methods based on argument types, this isn't really a problem either. To do fast dispatching you need to generate code anyway -- which as it turns out is *why* I've written decorators that create signature-specific wrappers. :) That is, the need to generate code exists even without having argument type declarations. Ergo, argument type declarations don't create any new problems; I was already generating custom wrappers to deal with other esoteric aspects of function signatures (like nested argument tuples, *args, and **kw). _______________________________________________ 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
