Multiple dispatch (was Re: PEP 484 change proposal: Allowing <at> overload outside stub files
On 24 January 2016 at 07:12, Stefan Krah <skrah.temporarily@gmail.com> wrote:
Right, the Blaze folks have been doing some very nice work in that area. One of the projects building on multipledispatch is the Odo network of data conversion operations: https://github.com/blaze/odo They do make the somewhat controversial design decision to make dispatch operations process global by default [1], rather than scoping by module. On the other hand, the design also makes it easy to define your own dispatch namespace, so the default orthogonality with the module system likely isn't a problem in practice, and the lack of essential boilerplate does make it very easy to use in contexts like an IPython notebook. There is one aspect that still requires runtime stack introspection [2], and that's getting access to the class scope in order to implicitly make method dispatch specific to the class defining the methods. It's the kind of thing that makes me wonder whether we should be exposing a thread-local variable somewhere with a "class namespace stack" that made it possible to: - tell that you're currently running in the context of a class definition - readily get access to the namespace of the innermost class currently being defined Cheers, Nick. [1] http://multiple-dispatch.readthedocs.org/en/latest/design.html#namespaces-an... [2] https://github.com/mrocklin/multipledispatch/blob/master/multipledispatch/co... -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Sat, Jan 23, 2016 at 6:45 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
I wonder if it wouldn't be acceptable to have a metaclass that takes care of the dispatch registry. You'd have a metaclass whose __prepare__ method produces a special kind of namespace that collaborates with a @dispatch() decorator. In this design, @dispatch() would not do the registration, it would just store its parameters on a function attribute and mark the function (or return some other object representing the dispatch parameters and the function). When the namespace receives a __setattr__() call with such an object, it registers it and if needed merges it with the object already there. Admittedly, calling inspect.currentframe() and assuming it never returns None is probably less code. (Hm, maybe sys._getframe() could be guaranteed to work inside a class scope?)
[1] http://multiple-dispatch.readthedocs.org/en/latest/design.html#namespaces-an... [2] https://github.com/mrocklin/multipledispatch/blob/master/multipledispatch/co...
-- --Guido van Rossum (python.org/~guido)
On Sat, Jan 23, 2016 at 6:45 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
I wonder if it wouldn't be acceptable to have a metaclass that takes care of the dispatch registry. You'd have a metaclass whose __prepare__ method produces a special kind of namespace that collaborates with a @dispatch() decorator. In this design, @dispatch() would not do the registration, it would just store its parameters on a function attribute and mark the function (or return some other object representing the dispatch parameters and the function). When the namespace receives a __setattr__() call with such an object, it registers it and if needed merges it with the object already there. Admittedly, calling inspect.currentframe() and assuming it never returns None is probably less code. (Hm, maybe sys._getframe() could be guaranteed to work inside a class scope?)
[1] http://multiple-dispatch.readthedocs.org/en/latest/design.html#namespaces-an... [2] https://github.com/mrocklin/multipledispatch/blob/master/multipledispatch/co...
-- --Guido van Rossum (python.org/~guido)
participants (2)
-
Guido van Rossum -
Nick Coghlan