[Python-3000] Discussions with no PEPs

[Talin]

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.
>