[Python-3000] PEP 3124 - Overloading, Generic Functions, Interfaces, etc.

[Phillip J. Eby]

At 04:19 PM 4/30/2007 -0700, Brett Cannon wrote:
>Doubt there is a ton of use for it, but any way to use this for pattern 
>matching ala Standard ML or Haskell?

Yes.  You have to provide a different dispatching engine though, as will be 
described in the currently non-existent "extension API" section.  :)

Perhaps you saw the part of the PEP with the "Pred('python expression 
here')" example?


>   Would be kind of neat to be able to do recursive function definitions 
> and choose which specific function implementation based on the length of 
> an argument.  But I don't see how that would be possible with this 
> directly.  I guess if a SingularSequence type was defined that overloaded 
> __isinstance__ properly maybe?  I have not followed the __isinstance__ 
> discussion closely so I am not sure.

No, the base engine will only support __issubclass__ overrides and other 
class-based criteria, as it's strictly a type-tuple cache system (ala 
Guido's generic function prototype, previously discussed here and on his 
blog).  However, engines will be pluggable based on predicate type(s).  If 
you use a predicate that's not supported by the engine currently attached 
to a function, it will attempt to "upgrade" to a better engine.

So, PEAK-Rules for example will register a predicate type for arbitrary 
Python expressions, and an engine factory for dispatching on them.


>Could you change __proceed__ to be a keyword-only argument?  That way it 
>would match the precedence of class definitions and the 'metaclass' 
>keyword introduced by PEP 3115.  I personally would prefer to control what 
>the default is if __proceed__ is not passed in at the parameter level then 
>have to do a check if it's NoApplicableMethod.

You would still have to check if its ``AmbiguousMethods``, though.

My current GF libraries use bound methods for speed, which means that the 
special parameter has to be in the first position.  ``partial`` and other 
ways of constructing a method chain for keyword arguments would be a lot 
slower, just due to the use of keyword arguments.  But it's certainly an 
option to use ``partial`` instead of bound methods, just a slower one.

(My existing GF libraries all target Python 2.3, where ``partial`` didn't 
exist yet, so it wasn't an option I considered.)