Guido van Rossum wrote: > I don't think a consensus has been reached on any of these. > > My votes: > > - generic functions: no
Here's how I would summarize the current state of generic functions. 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. 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. 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. 4) If 3.0 includes a standard dispatcher, to what extent should the standard libraries be allowed to depend on generic functions? In other words, should things like the new i/o library be written to depend on the existence of a built-in dispatcher? 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?) Before we get a flood of answers to these questions, let's make sure that these are, in fact, the right questions. > - interfaces: no, but I'd like to work on ABCs instead > - metaclass syntax: I'd like to see your PEP > > --Guido > > On 3/7/07, Talin <[EMAIL PROTECTED]> wrote: >> Going back in this list, I see a number of issues which were discussed >> at length, but there is no corresponding PEP. I realize that in some >> cases, this is because no actual consensus was reached. >> >> In any case, I would like to know, what is the current status of the >> following issues: >> >> -- Generic Functions >> -- Interfaces >> -- Metaclass syntax >> >> It's not my intention to start a big thread about these - anyone who >> wants to can go back and read the old discussions. I mainly would like >> to know: >> >> 1) Was there a final pronouncement, or at least a rough consensus on >> either of these? If so, what was it? >> 2) Should these have PEPs? (Even if solely for purposes of rejection?) >> 3) If they are not ready for PEPs, should the discussions be >> restarted on Python-ideas? >> >> In order to prevent a major thread, I would suggest that any response >> that is not a direct answer to one of the above questions should be >> moved to python-ideas. Specifically, I'd like to avoid any discussion of >> the *merits* of the ideas themselves, or alternative solutions - let's >> limit the comments to just talking about their *status*. >> >> And if you need someone to write those PEPs, I can do it - but I'll need >> some help on the first two in order to understand all of the sides of >> the controversy. The third one is pretty easy. > _______________________________________________ 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
