[Python-ideas] ML Style Pattern Matching for Python

[Bruce Leban]

On Sat, Dec 18, 2010 at 4:40 PM, Eike Welk <eike.welk at gmx.net> wrote:

> I would love to see this implemented! Off course I like my syntax better.
> :-)
>
> well, I have to agree with Terry that your syntax looks like chicken
scratches. Terseness is not a synonym for elegant. In this proposal, I'm
using a terse syntax in two places where I think a less terse syntax would
be too verbose. For references, I used & which mirrors the familiar C
reference syntax, and for extra arguments, I used * which mirrors the use of
that in function parameter lists. Arguably, I should be using * when the
result is a list and ** when the result is a dict, but that's a detail not
worth obsessing about at this point, since this is pretty unlikely to get
added to the language. :-)



> On Saturday 18.12.2010 22:26:05 Bruce Leban wrote:
> > Whether or not this is useful at all is a big question, but I think it's
> at
> > least more interesting. This isn't perfect. For example
> >
> > x matches Foo(a=&alpha, b=&beta)
>
> For this case I prose that the class "Foo" should implement a special
> function
> "__rinit__" that breaks an instance apart, into components that can be
> matched. These components should be chosen so that they could be given to
> "__init__" as its arguments.
>
> "__rinit__" should return the following objects:
> * a tuple of objects, corresponding to the regular arguments of "__init__".
> * a tuple of strings that contains the argument names.
> * a dict of string:object that represents the keyword only attributes.
>

This doesn't work. Positional and keyword arguments are not mutually
exclusive. Furthermore, it may be a significant amount of work to
unconstruct an object just to find out if it has an attribute. And some
classes aren't "unconstructable".


>
> A type check would be expressed like this:
>
>        x matches Foo(&*_)


That would just be

x matches Foo(*)


There's no need to bind the results to something.

 > could mean checking x.hasattr('a') but there's no guarantee that Foo(a=1,
> > b=2) will produce that result. Maybe that's OK.
> >
> > Also, any values on the right hand side not marked by & are matched for
> > equality, so you could write
> >
> > x matches (3 * 14 + big_complicated_expression, &y)
>
> It's really neat, but maybe too much visual clutter. It should be discussed
> if
> the following looks better:
>
>    x matches (x, y) and x == 3 * 14 + big_complicated_expression
>

Um, this was a *bad* example, indicating how the feature can be misused.
There's no need to "discuss" the alternative you give though. The matches
expression could be combined just like any other expression. So you could
write:

x matches (&k, &y) and k == some_expression


or

k = some_expression
x matches (k, &y)


I'm unsure about it.
>
>
> > which is pretty ugly. And that suggests:
> >
> > x matches (f(&y), g(&z))
>
> It can only work with the few functions that are bijective. Many algorithms
> destroy information and can therefore not be run backwards.
>
>
Again, this was a *bad* example.

>
> --- Bruce
Latest blog post: http://www.vroospeak.com/2010/11/enduring-joe-barton.html
Learn about security: http://j.mp/gruyere-security
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20101219/e8fcd2a7/attachment.html>