I'm not sure how your proposal fits in here, but it looks like the current if-elif-else syntax is better suited to it than some trying to use a switch-dictionary with some special objects to implement wild-card matching, e.g.

The wildcard object isn't very important; the part that matters is being able to take structures apart using case clauses. Also, this is mostly about syntactical convenience - for certain problems, pattern-matched case statements read better and are less error-prone than if-then-elif syntax. But I need to come up with a better example. Anyway, my main point is just to argue in favor of switch syntax rather than looking for special cases of if-then-elif to optimize. Some languages do some very elegant things with switches that Python might want to implement someday. (I do appreciate that the dictionary optimization only works for the simple case though, so comparison to constants is the only part that's needed to start.) - Brian

In languages with pattern matching, you find that they use it to emulate late binding: depending on the structure of a thing, you perform different code. In Python, this is more easily done using methods of the object, which naturally dispatch based on the type of the object.

Method dispatch is a great technique and I was once in the "all case statements are insufficiently object-oriented" camp. But sometimes you need to work with base types or other people's classes without subclassing them, so I find myself writing long if-then-elif statements (most recently for a memory profiler), and case statements would make this code clearer. (Though not nice enough to switch languages, in particular to Prolog.) re: "Classes don't participate that easily in pattern matching" True for many classes and I'll admit my proposal was quarter-baked. Even matching on base types like tuple, list, and dictionary would be plenty interesting. (Especially since they're subclassable.) - Brian

Greg Ewing wrote:

Brian Slesinsky :

...

But sometimes you need to work with base types or other people's classes without subclassing them

I think there are situations where it's legitimate to prefer a case-statement approach even when dealing with your own classes.

I once wrote a compiler in HUGS (a Haskell dialect), and I found it very convenient to be able to write a self-contained function which took a parse tree node and did something for each possible subtype of that node. It kept all the processing related to each phase of the compiler together in one place.

Using a pure OO aproach, I would have had to scatter it all among hundreds of one or two-line methods of many classes, and probably would have gone insane before finishing the project.

Right. IMO, the method callback approach is nice if you need an extendable architecture, e.g. to write generic parsers frameworks. It doesn't pay off in situations where you have a set of fixed requirements. In these cases, the performance gain is more important than being able to extend by subclassing. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/