This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: matmul @ operator precedence
Type: enhancement Stage: resolved
Components: Interpreter Core Versions: Python 3.8
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: FabriceSalvaire, eric.smith, mark.dickinson, steven.daprano
Priority: normal Keywords:

Created on 2018-04-29 19:49 by FabriceSalvaire, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (5)
msg315918 - (view) Author: fabrice salvaire (FabriceSalvaire) Date: 2018-04-29 19:49
I use the new matmul @ operator to implement units, for example 1@u_s for 1 second ( see alpha state implementation at https://github.com/FabriceSalvaire/PySpice/tree/master/PySpice/Unit ).

It looks cool, but unfortunately 10@u_s / 2@u_s is actually interpreted as (10@u_s / 2)@u_s instead of (10@u_s) / (2@u_s) due to operator precedence + <<< - <<< * <<< @ <<< / <<< // <<< % https://docs.python.org/3/reference/expressions.html#operator-precedence

Since Python is widely used for scientific applications, would it be possible to investigate this topic ?
msg315922 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2018-04-29 22:54
Operator precedence cannot change without breaking existing code.
msg315923 - (view) Author: Steven D'Aprano (steven.daprano) * (Python committer) Date: 2018-04-30 00:10
Precedence issues when dealing with units is unavoidable, I think. The units program on Linux/Unix has similar issues, and they write their own parser and choose their own precedence.

https://www.gnu.org/software/units/manual/html_node/Operators.html

As Eric says, we can't change the precedence of the @ operator easily, if at all. It would likely require at least one full release (3.8) with a warning, or a future import, and frankly if the numpy community is against it you'll have zero chance of it happening. (On the other hand, if they're in favour of it, you'll have a good chance.)

If you still want to pursue this idea further, please take the idea to the numpy and/or Python-Ideas mailing lists for further discussion:

https://www.scipy.org/scipylib/mailing-lists.html

https://mail.python.org/mailman/listinfo/python-ideas

but for now I'm going to set the issue to pending.
msg315933 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2018-04-30 07:42
[Steven]
> please take the idea to the numpy and/or Python-Ideas mailing lists for further discussion:

But please do read through the previous discussions before starting a new one! See the links in PEP 465, and particularly https://mail.scipy.org/pipermail/numpy-discussion/2014-March/069444.html
msg315934 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2018-04-30 07:43
Gah! Forgot that my post would reset this issue to open. I'm going to close here, since this would be a sufficiently big and unlikely change that it's not going to happen without a python-ideas/python-dev discussion.
History
Date User Action Args
2022-04-11 14:58:59adminsetgithub: 77571
2018-04-30 07:43:24mark.dickinsonsetstatus: open -> closed
resolution: postponed -> rejected
messages: + msg315934

stage: resolved
2018-04-30 07:42:23mark.dickinsonsetstatus: pending -> open
nosy: + mark.dickinson
messages: + msg315933

2018-04-30 00:10:13steven.dapranosetstatus: open -> pending

nosy: + steven.daprano
messages: + msg315923

resolution: postponed
2018-04-29 22:54:58eric.smithsetversions: + Python 3.8, - Python 3.5
nosy: + eric.smith

messages: + msg315922

type: behavior -> enhancement
2018-04-29 19:49:56FabriceSalvairecreate