[Python-3000] Discussions with no PEPs

[Phillip J. Eby]

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