[Python-ideas] [RFC] draft PEP: Dedicated infix operators for matrix multiplication and matrix power

Bruce Leban bruce at leapyear.org
Mon Mar 17 04:46:08 CET 2014


On Sat, Mar 15, 2014 at 12:35 AM, Steven D'Aprano <steve at pearwood.info>wrote:

> On Fri, Mar 14, 2014 at 09:09:02PM -0700, Bruce Leban wrote:
> > I think making @ right associative would make this less suitable for
> other
> > uses. Example
> >
> > someclassobject @ somevalue @ somevalue
> >
> > won't work with right-associativity.
>
> Why not? It works with the other right-associative operator:
>
>     x**y**z
>

It won't work because right-associativity means that the two values on the
right are combined together first and they won't be combined properly.
given that the type of someclassobject is not consulted.


>
> "Works" depends on what you expect it to do. Unless you tell us what
> these "other uses" are, how can we know that right-associativity won't
> work?
>

Here's a simple example to illustrate the concept. Suppose I have a class
that is roughly equivalent to a dict mapping values to lists of values,
e.g.,

a = {
    1: [10, 11, 12]
}
b = {
    1: [11, 13]

}


I might have

a + b = {

    1: [10, 11, 12, 11, 13]  # appends

}

a @ b = {

    1: [10, 11, 12, 13]  # appends non-duplicate values

}


but I also want to be able to merge in standard dicts. If @ is
right-associative, a @ x @ y where x and y are dicts, will try to compute x
@ y first and built-in dict doesn't supporr the @ operator. Even if it did,
it's not going to do what I'd want here.

I also want to give a larger example to illustrate the kind of thing I
think this operator would be useful for. SQLAlchemy has query objects where
you can write something like

some_query.filter(...).order_by(...).join(...)


I image that this could use the @ operator:

some_query @ filter(...) @ order_by(...) @ join(...)


The benefit here is that I have filter objects, order_by objects, etc. that
can be passed around rather than only having API calls. In the current API,
it's clumsy to support that as I either need both filter objects and a
query.filter method or I need a clumsy query.apply method. Having an
@operator I think works really well. Left vs. right associativity is
useful
if I wanted to support other kinds of objects on the right hand side of the
@, e.g., if:

some_query @ { column1: value1, column2: value2, ... }


as another spelling of

some_query @ filter(column1=value1, column2=value2, ... }


--- Bruce
Learn how hackers think: http://j.mp/gruyere-security
https://www.linkedin.com/in/bruceleban
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140316/7fb4c9a5/attachment.html>


More information about the Python-ideas mailing list