At 07:47 PM 5/14/2007 -0700, Talin wrote: >Guido van Rossum wrote: >>Next, I have a question about the __proceed__ magic argument. I can >>see why this is useful, and I can see why having this as a magic >>argument is preferable over other solutions (I couldn't come up with a >>better solution, and believe me I tried :-). However, I think making >>this the *first* argument would upset tools that haven't been taught >>about this yet. Is there any problem with making it a keyword argument >>with a default of None, by convention to be placed last? > >I earlier suggested that the __proceed__ functionality be >implemented by a differently-named decorator, such as "overload_chained". > >Phillip objected to this on the basis that it would double the >number of decorators. However, I don't think that this is the case, >since only a few of the decorators that he has defined supports a >__proceed__ argument - certainly 'before' and 'after' don't (since >they *all* run), and around has it implicitly. > >Also, I believe having a separate code path for the two cases would >be more efficient when dispatching.
This isn't so. Method combination only takes place when a particular combination of arguments hasn't been seen before, and the result of combination is a single object. That object can be a bound method chain, which is *very* efficient. In fact, CPython invokes bound methods almost as quickly as plain functions, as it has a C-level check for them. In any case, if a method does not have a next-method argument, the resulting "combined" method is just the function object, which is called directly. (PEAK-Rules, btw, doesn't incorporate this bound-method-or-function optimization at the moment, but it's built into RuleDispatch and is pretty darn trivial.) >The problem of course is that I don't know how to build an efficient >dispatch table to do that, and I'm not even sure that it's possible. Oh, it's possible all right. The only tricky bit with the proposal under discussion is that I need to know the maximum arity (number of arguments) that the function is ever dispatched on, in order to build a dispatch tuple of the correct length. Missing arguments get a "missing" class put in the corresponding tuple position. The rest works just like normal type-tuple dispatching, so it's really not that complex. _______________________________________________ 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