Skip to content

Pattern matching in Python

monkey.org
38 pointsmariusae6 comments
On HN

Comments

While pattern matching is one of my favorite things about OCaml, I'm not sure this fits well in Python. A big part of Python is trying to keep the language from being all things to all people and accumulating esoteric cruft, especially in the syntax. If I ran the zoo, I would have probably chosen a slightly different subset of features for Python, but I have a lot of respect for Guido's intent.

Also, doing anything by overloading arithmetic operators for a semantically unrelated purpose tends to be pretty disharmonious with the rest of the language. The only exception I can think of is Lua's LPEG (http://www.inf.puc-rio.br/~roberto/lpeg/lpeg.html), but that's a specific sub-language that tends to be clearly isolated to grammars; in practice, it's usually as distinct as using * within regular expression strings.

Cool.

I wrote some pattern matching code myself for python a few months back just for fun. It was extremely unpythonic, but a fun exercise. For comparison, here's my code:

http://github.com/paulgb/python-pattern-matching/tree/master

This adds a neat Prolog-angle to the whole language. Cant wait to see if someone actually makes a complete prolog-module out of this.

While I don't have direct experience with either of these (I just googled for "python prolog backtracking"), you could probably do just as well in idiomatic Python using generators:

  * http://codespeak.net/pypy/extradoc/paper/prolog-in-python.pdf
  * http://mail.python.org/pipermail/python-list/2005-October/348485.html
I think Peter Norvig has written about this, too.

I'm not sure, I don't think python semantics would support implicit backtracking.

That is terribly un-Pythonic, and a poor imitation to boot. Neat proof of concept though.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.