[Python-3000] Discussions with no PEPs (original) (raw)

Talin talin at acm.org
Thu Mar 8 08:49:04 CET 2007

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 <talin at acm.org> 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.

More information about the Python-3000 mailing list