At 11:49 PM 3/7/2007 -0800, Talin wrote: >Function decorators + argument decorators already provide everything >needed for a third-party developer to implement generic functions on >their own. In other words - you could create an add-on module that >provides the proper function decorators that would be capable of >interpreting argument types and building whatever kind of dispatch table >you wanted, without having any further support in the base language >other that what's already there now. > >I understand that Phillip J. Eby, whose experience with generic >functions is well known, is interested in having the ability to replace >the standard dispatcher. I believe that this requires no further effort >on our part, but I welcome corrections on that point.
The above is correct. >So, to my mind, there are really only a few issues to be answered: > >1) Whether Python 3K should provide a 'standard' implementation of those >generic function decorators. > >2) if so, should it provide one with the initial release of Py3K (i.e. >3.0), or should we wait for various 3rd party modules to emerge, compete >in the marketplace, and then pick a winner to be blessed with 'official' >status. I think 3.1 or 3.2 are soon enough, and will give some time for competitors to appear and stabilize. >3) if a 'standard' implementation is to be included with the 3.0 >release, should it be an optimized, native-code dispatcher, or a 'pure >python' implementation. Moreover, will any changes to the Python >interpreter be required to get the best possible dispatch performance >with generic functions. This is a (somewhat) open question. There are some tradeoffs that need to be made between speed and dynamicity. My libraries (and Guido's tuple-caching prototype) assume that you are not (for example) changing class' __bases__ at runtime, in order to be able to cache things. Of course, if some 3.x version grew the ability to register Python-accessible callbacks for class or module changes, then we could implement a few other long-desired optimizations, and this tradeoff for generic functions would go away. >Note that this does not address PJE's 'defop' concerns, which (according >to my understanding) isn't so much about dispatch mechanisms as it is >about the ability to spread the definition of a generic function over >multiple source files, so that the methods that operate on a given class >can be grouped of that class's definition. The primary motivation is to >customize the behavior of a built-in function or operator on a given >type, without having to either define a new __special__ method, or >monkey patch the built-in function in some way. (Is this correct?) Yes and no. The primary motivation (for me, anyway) is to have a more usable syntax for defining overloads or generic function methods, that doesn't require you to create a dummy function name. Being able to possibly get rid of __special__ methods would be a nice bonus. (Of course, if we could get some "blocks" or anonymous functions, that might be another way to solve the problem. However, nobody has yet come up with a workable syntax for that.) _______________________________________________ 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
