Agreed but does this apply in Numpy as well? Will Python matrix multiplications just work on lists of lists in which case they're much slower? Sorry just asking from a 2.7 holdout here as this might cause me to move.

"An upcoming release of NumPy 1.10 will add support for the new operator" [1]

[1] https://docs.python.org/3.5/whatsnew/3.5.html

The matrix multiplication operator is not implemented for any standard python data type.

The matrix multiplication PEP is actually titled "A dedicated infix operator for matrix multiplication", and that's (broadly) the only thing that it provides. Here's the arguments for why the operator should exist: https://www.python.org/dev/peps/pep-0465/#why-should-matrix-...

numpy and other libraries might/has/will implement the matrix multiplication infix operator for their array and matrix data types.

From:

http://legacy.python.org/dev/peps/pep-0465/#id24

Implementing __matmul__, __rmatmul__ and __imatmul__ will allow you to apply this operator to any given class. In that light, you could subclass the numpy matrix class yourself and simply apply these.

As for whether these will be applied to Python lists, my speculation is: I doubt it. Its possibly the most commonly used data structure, and I doubt they would add the overhead of another set of methods on each instance.

The matrix multiplication on lists could be used for the cartesian product (see itertools.product). However this operation is rather uncommon so there's no good reason to use an operator for it.

It wouldn't incur any overhead, don't know why you'd think it would. Each method of any object only needs to be stored once, not again for every instance. The overhead comes from pointers and data fields such as the length.

> Its possibly the most commonly used data structure, and I doubt they would add the overhead of another set of methods on each instance.

Unless I'm grossly mistaken, Python methods add basically no per-instance overhead (they add per-class overhead.)

Doubt it. The @ symbol isn't implemented by default. It's just available as a syntactic element primarily for NumPy to use, though other libraries are free to use it as well.

I want to see it used for an XML library, since I think node@"name" is a more succinct, and domain-appropriate equivalent for node.attrib.get("name").

I have kind of mixed feelings. The biggest argument against that PEP was that people would use it for things that are very unlike matrix multiplication, which can be confusing. I can kind of see the point there, but on the other hand the @ symbol really is natural for things like what you suggest.

Unusual operator overloading isn't that common in Python, though '%' for string processing is a big and primordial exception. Of the packages I know which use it, only PyParsing uses overloading for something non-analogous to the normal meanings.

I tried hard to think of ways to (ab)use '@', and this XML example and perhaps some sort of messaging API were the only two I could come up with where there was a natural domain-specific mapping.

One of the advantages of keeping '@' at the same precedence level and ordering as '*', '/', '%', and '//' is that it doesn't really offer much in the way of new use. If someone uses '@' for something very unlike matrix multiplication, then they could already use any of the other 4 symbols that way.

So I don't think @ ends up as an attractive nuisance.

It's a bit of a weak argument when pathlib is in the stdlib: https://www.python.org/dev/peps/pep-0428/#deriving-new-paths

Why not just use the array indexing operator for that?

In which way? node[1] means the second child.

If you mean node[x] returns node.attrib.get(x) when x is a string, and the nth-child when x is an integer, then I think that puts too much complexity into the API.

If you mean stay with the existing node.attrib dict-like API, then node@name is a simple shortcut for node.attrib.get(name), but it's 1) more aligned with CSS/XSL '@' notation for attribute syntax, and 2) faster in CPython.

(Just realized that '/' and '//' also make sense in that context. node / "abc" / "xyz" @ "p" would be the child "abc"'s child "xyz"'s attribute "p". Perhaps my proposal is a bad idea because it might suggest that these other forms are allowed.)

If you grab the latest code in master from https://github.com/numpy/numpy you'll get support for @ in numpy. It's great!

The @ operator won’t apply to any built-in data types. It’s only designed for numpy and other libraries.