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