[Python-3000] PEP 3124 - Overloading, Generic Functions, Interfaces, etc. (original) (raw)

Phillip J. Eby pje at telecommunity.com
Tue May 1 02:02:47 CEST 2007

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

More information about the Python-3000 mailing list