So far, I’ve only really watched the development of the generic function stuff, never used it, but my instinct says that I would use the “lower-level” API if at all possible, and avoid the string form whenever I could. If Python supported an “expression literal” form which was used here instead of strings, I’d be a lot happier. No idea why. Maybe it’s something as silly as the syntax highlighting my editor applies…

In any case, the @foo.when(Signature(x=int,y=int)) example I showed in the comments on your blog is functionally equivalent to the isinstance() string form, and you can do Signature(x=str,y=str) | Signature(x=unicode,y=unicode) to “or” signatures together. So, if you prefer not to use strings for when() conditions, you can construct predicates and signatures using the lower-level dispatch API. (That is, you can directly build the structure that the parser would build from a string.)

I have to say, I just cringe when I see any kind of API that takes a string containing Pythonesque syntax a la our where() predicate. But we should probably take that offline (and I understand the constraints under which you are working.)

Part of the reason I point this out is so that people stumbling across this page don’t end up thinking that Guido’s code is “better” than using the dispatch module, or — even worse! — they actually use this code.

If you really want the semantics of Guido’s example and you’re using PyProtocols, you should use @foo.when("type(a) is int and type(b) is int") and not reimplement all these wheels. And if you want multiple signatures for a single method, then @foo.when("type(a) is str and type(b) is str or type(a) is unicode and type(b) is unicode") also works as intended. There’s then no need for last-method attribute hacks or stacked decorators.