On 7/20/06, Talin <[EMAIL PROTECTED]> wrote: > However, in order to use type annotations, one needs to associate > between the actual arguments and the formal parameters - because the > annotations are keyed by the formal parameter they are attached to. One > way to do this is to simulate the mapping of arguments to formal > parameters within the decorator. Once you know which formal parameter a > given value is assigned to, you can then retrieve the annotation for > that parameter and apply it to the value. > > However, there are a number of drawbacks to doing this - first, the > mapping algorithm isn't really that simple in the general case. Worse, > the assignment of arguments to formal parameters is a prime suspect in > the relative 'slowness' of Python function calls compared to other > language features - and in order for the decorator to figure out which > argument goes with which formal parameter, the decorator is now forced > to perform that same mapping *again*. [snip] > A different possibility is to attempt to do the mapping in reverse - > that is, for a given formal parameter (and its associated type > annotation), attempt to determine which input argument corresponds to > that parameter. > > The problem with this notion is that the parameter mapping algorithm is > an iterative one - it would be difficult to come up with an algorithm > that does Python parameter assignment *in reverse*, that was guaranteed > to be correct for all possible edge cases.
I've implemented both solutions before, and neither proved to be all that difficult (after actually reading the manual, that is ; ) Also, I'm not sure what you're considering to be 'the general case', but I remember from my own adventures in this area that the most frequent function types were "def foo(a, b, c)"-style functions, ie, functions with only positional arguments. In this case, the mapping becomes dead simple. > By saying that annotations have no fixed meaning, what we're really > saying is that there's no "standard interpretation" of these > annotations, and that's where IMHO the trouble lies. If there's no > standard interpretation, then everyone is going to interpret them > differently. A function with more than one independently-written > decorator is going to have problems, each decorator trying to pick out > the parts of the annotations that's meant for them and not the others. Guido and I went back and forth on this for a while, whether or not to include a "standard interpretation" with Python itself. We're counting on the shear complexity of implementing an annotation-interpreting library to keep the number of these libraries low and in the hands of people who know what they're doing. > It seems to me that a better solution is to allow the *decorators* to > have function signatures. For example: > > @overload(int,int) > def add(a,b): > ... > > The advantage of this is twofold: [snip] > Second, it means that the mapping problem hasn't entirely gone away, but > has somewhat been reduced, because now the type annotations are > referring to the *wrapper function's* arguments, not the arguments of > the wrapped function. This means that the wrapper is now on the > 'inside', and can see all of the variables in their mapped configuration. Huh? Unless you have a raft of decorators for every possible permutation of function parameters, you've probably written that overload() decorator to have a signature of "def overload(*vargs)" or "def overload(*vargs, **kwargs)", in which case you still have to do the argument -> formal parameter mapping. > Of course, there is still the problem of passing the arguments to the > inner function - but that's no worse than the problem that decorators > have today. I don't understand; what kind of decorators do you write that have this problem? > For example, '@overload(int,int,a=int)' doesn't express the notion that a is > a keyword argument that should be constrained to an int value. It certainly can express that if you want it to. Just use **kwargs in the decorator to catch all keyword arguments and then treat them differently. Collin Winter _______________________________________________ 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
