- Python Home
- About
- News
- Documentation
- Downloads
- Community
- Foundation
- Developer's Guide
- Issue Tracker
- Issues
- Summaries
- User
- Administration
- Help
Issue43837
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.
Created on 2021-04-14 04:38 by aidan.feldman, last changed 2022-04-11 14:59 by admin. This issue is now closed.
| Pull Requests | |||
|---|---|---|---|
| URL | Status | Linked | Edit |
| PR 25469 | merged | ammar2, 2021-04-19 04:49 | |
| PR 25472 | merged | miss-islington, 2021-04-19 15:22 | |
| Messages (12) | |||
|---|---|---|---|
| msg391030 - (view) | Author: Aidan Feldman (aidan.feldman) | Date: 2021-04-14 04:38 | |
I am teaching a class on Python for people who are new to coding, and I was talking them through the operator precedence table: https://docs.python.org/3/reference/expressions.html#operator-precedence A couple things that confused the students: - "Highest precedence" is on the bottom, while "lowest precedence" is on top - There isn't any mention of variables. While not operators, probably worth mentioning that they (effectively?) have higher precedence than any of the operators. I'd be happy to try making my first contribution to Python if there's interest in those edits. Also, I have an example breaking down operator precedence in practice here, which I could include: https://colab.research.google.com/github/afeld/python-public-policy/blob/main/lecture_2.ipynb#scrollTo=UTxeT5RvqSFl Thanks! |
|||
| msg391044 - (view) | Author: Steven D'Aprano (steven.daprano) * ![]() |
Date: 2021-04-14 08:16 | |
> There isn't any mention of variables. While not operators, probably worth mentioning that they (effectively?) have higher precedence than any of the operators. I'm sorry, I don't understand what that means. |
|||
| msg391106 - (view) | Author: Aidan Feldman (aidan.feldman) | Date: 2021-04-14 22:39 | |
Let me try and say a simpler way: I think "variables" should be mentioned in that section, either in the table or the paragraph above. |
|||
| msg391107 - (view) | Author: Zachary Ware (zach.ware) * ![]() |
Date: 2021-04-14 22:55 | |
I think it might be easiest to see your suggestion as a pull request :) |
|||
| msg391259 - (view) | Author: Terry J. Reedy (terry.reedy) * ![]() |
Date: 2021-04-16 21:11 | |
When I looked at the table yesterday (after several years), I was initially confused at the 'reversed' order (before I checked the text above). Besides precedence usually (nearly always) being listed high to low*, the chapter itself is highest to lowest, so the table is reversed from the chapter order. * I checked K&R C and several sites and images and all I saw had highest at the top (highest). This include other Python charts. The table has been this way since at least 1.4 https://docs.python.org/release/1.4/ref/ref5.html#HDR18 Guido, how would you feel about reversing it to follow what seems to be the de facto standard? The header 'Operator' could be changed to 'Operator (lowest first)' but I would prefer to make that 'Operator (highest first)'. |
|||
| msg391260 - (view) | Author: Guido van Rossum (Guido.van.Rossum) | Date: 2021-04-16 21:21 | |
I defer to Raymond on this. Honestly without looking at the website I don’t even recall whether “higher precedence” means “binds more tightly” or the opposite. :-) So maybe we should change the terminology while we’re at it. |
|||
| msg391361 - (view) | Author: Raymond Hettinger (rhettinger) * ![]() |
Date: 2021-04-19 04:28 | |
Let's reverse the table in accordance with the de facto standard. |
|||
| msg391362 - (view) | Author: Ammar Askar (ammar2) * ![]() |
Date: 2021-04-19 04:55 | |
Opened https://github.com/python/cpython/pull/25469 for the first suggestion of reversing the precedence table order since it seems like a good improvement. I think the tight binding to weak order is more natural and aside from K&R, the following other languages also follow the same ordering: * Javascript - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Operator_Precedence#table * PHP - https://www.php.net/manual/en/language.operators.precedence.php * Rust - https://doc.rust-lang.org/reference/expressions.html#expression-precedence |
|||
| msg391364 - (view) | Author: Chris Jerdonek (chris.jerdonek) * ![]() |
Date: 2021-04-19 05:24 | |
> So maybe we should change the terminology while we’re at it. When math is taught to elementary school students in the US, it's called "order of operations": https://en.wikipedia.org/wiki/Order_of_operations Since this was raised in the context of newcomers to coding, it might be worth mentioning that parallel. Being able to connect to the familiar concepts of "first" and "last" might help people not familiar with precedence and binding. |
|||
| msg391381 - (view) | Author: Raymond Hettinger (rhettinger) * ![]() |
Date: 2021-04-19 15:22 | |
New changeset 68ba0c67cac10c2545ea3b62d8b161e5b3594edd by Ammar Askar in branch 'master': bpo-43837: Reverse order of precedence table to show tightly binding operators first (GH-25469) https://github.com/python/cpython/commit/68ba0c67cac10c2545ea3b62d8b161e5b3594edd |
|||
| msg391384 - (view) | Author: Raymond Hettinger (rhettinger) * ![]() |
Date: 2021-04-19 15:56 | |
New changeset 072ec69af592611f36349f5048569ab7e72b8b61 by Miss Islington (bot) in branch '3.9': bpo-43837: Reverse order of precedence table to show tightly binding operators first (GH-25469) (GH-25472) https://github.com/python/cpython/commit/072ec69af592611f36349f5048569ab7e72b8b61 |
|||
| msg391385 - (view) | Author: Raymond Hettinger (rhettinger) * ![]() |
Date: 2021-04-19 16:10 | |
* Changed the table order to match norms. * Not adding and for variables because that is outside the norm (likely because variables aren't operators). * Keeping the existing terminology which is standard and historically hasn't been a problem. Also the tone and level matches that for the rest of the reference guide. Thank you all for your input. |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022-04-11 14:59:44 | admin | set | github: 88003 |
| 2021-04-19 16:10:14 | rhettinger | set | status: open -> closed resolution: fixed messages: + msg391385 stage: patch review -> resolved |
| 2021-04-19 15:56:45 | rhettinger | set | messages: + msg391384 |
| 2021-04-19 15:22:45 | miss-islington | set | nosy:
+ miss-islington pull_requests: + pull_request24198 |
| 2021-04-19 15:22:23 | rhettinger | set | messages: + msg391381 |
| 2021-04-19 05:24:46 | chris.jerdonek | set | nosy:
+ chris.jerdonek messages: + msg391364 |
| 2021-04-19 04:55:30 | ammar2 | set | messages: + msg391362 |
| 2021-04-19 04:49:38 | ammar2 | set | keywords:
+ patch nosy: + ammar2 pull_requests: + pull_request24194 stage: patch review |
| 2021-04-19 04:28:45 | rhettinger | set | assignee: rhettinger -> |
| 2021-04-19 04:28:21 | rhettinger | set | messages: + msg391361 |
| 2021-04-19 02:56:21 | rhettinger | set | assignee: docs@python -> rhettinger |
| 2021-04-16 21:21:22 | Guido.van.Rossum | set | nosy:
+ rhettinger, Guido.van.Rossum messages: + msg391260 |
| 2021-04-16 21:11:55 | terry.reedy | set | nosy:
+ terry.reedy, gvanrossum messages: + msg391259 |
| 2021-04-14 22:55:20 | zach.ware | set | nosy:
+ zach.ware messages: + msg391107 |
| 2021-04-14 22:39:46 | aidan.feldman | set | messages: + msg391106 |
| 2021-04-14 08:16:45 | steven.daprano | set | nosy:
+ steven.daprano messages: + msg391044 |
| 2021-04-14 04:38:05 | aidan.feldman | create | |


