5 ms·

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

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.

gh02t 11y ago
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.
- dalke 11y ago
  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").
  - gh02t 11y ago
    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.
    - dalke 11y ago
      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.
    - Macha 11y ago
      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 https://www.python.org/dev/peps/pep-0428/#deriving-new-paths
  - iso8859-1 11y ago
    Why not just use the array indexing operator for that?
    - dalke 11y ago
      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.)
jacobolus 11y ago
The @ operator won’t apply to any built-in data types. It’s only designed for numpy and other libraries.
jdimov9 11y ago
"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 https://docs.python.org/3.5/whatsnew/3.5.html
jwandborg 11y ago
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-multiplication-be-infix 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.
servbot 11y ago
From: http://legacy.python.org/dev/peps/pep-0465/#id24 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.
- andreasvc 11y ago
  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.
- dragonwriter 11y ago
  > 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.)
nwhitehead 11y ago
If you grab the latest code in master from https://github.com/numpy/numpy https://github.com/numpy/numpy you'll get support for @ in numpy. It's great!

gh02t 11y ago

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.

dalke 11y ago
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").
- gh02t 11y ago
  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.
  - dalke 11y ago
    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.
  - Macha 11y ago
    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 https://www.python.org/dev/peps/pep-0428/#deriving-new-paths
- iso8859-1 11y ago
  Why not just use the array indexing operator for that?
  - dalke 11y ago
    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.)

jacobolus 11y ago

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

jdimov9 11y ago

"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 https://docs.python.org/3.5/whatsnew/3.5.html

jwandborg 11y ago

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-multiplication-be-infix 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.

servbot 11y ago

From: http://legacy.python.org/dev/peps/pep-0465/#id24 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.

andreasvc 11y ago
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.
dragonwriter 11y ago
> 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.)

nwhitehead 11y ago

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