[issue43837] Operator precedence documentation could be more clear

Raymond Hettinger added the comment: * 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

[issue43837] Operator precedence documentation could be more clear

Raymond Hettinger added the comment: 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)

[issue43837] Operator precedence documentation could be more clear

Change by miss-islington : -- nosy: +miss-islington nosy_count: 10.0 -> 11.0 pull_requests: +24198 pull_request: https://github.com/python/cpython/pull/25472 ___ Python tracker

[issue43837] Operator precedence documentation could be more clear

Raymond Hettinger added the comment: New changeset 68ba0c67cac10c2545ea3b62d8b161e5b3594edd by Ammar Askar in branch 'master': bpo-43837: Reverse order of precedence table to show tightly binding operators first (GH-25469)

[issue43837] Operator precedence documentation could be more clear

Chris Jerdonek added the comment: > 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

[issue43837] Operator precedence documentation could be more clear

Ammar Askar added the comment: 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, the following other languages

[issue43837] Operator precedence documentation could be more clear

Change by Ammar Askar : -- keywords: +patch nosy: +ammar2 nosy_count: 8.0 -> 9.0 pull_requests: +24194 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25469 ___ Python tracker

[issue43837] Operator precedence documentation could be more clear

Change by Raymond Hettinger : -- assignee: rhettinger -> ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43837] Operator precedence documentation could be more clear

Raymond Hettinger added the comment: Let's reverse the table in accordance with the de facto standard. -- ___ Python tracker ___

[issue43837] Operator precedence documentation could be more clear

Change by Raymond Hettinger : -- assignee: docs@python -> rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue43837] Operator precedence documentation could be more clear

Guido van Rossum added the comment: 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. -- nosy:

[issue43837] Operator precedence documentation could be more clear

Terry J. Reedy added the comment: 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,

[issue43837] Operator precedence documentation could be more clear

Zachary Ware added the comment: I think it might be easiest to see your suggestion as a pull request :) -- nosy: +zach.ware ___ Python tracker ___

[issue43837] Operator precedence documentation could be more clear

Aidan Feldman added the comment: 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. -- ___ Python tracker

[issue43837] Operator precedence documentation could be more clear

Steven D'Aprano added the comment: > 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. -- nosy: +steven.daprano

[issue43837] Operator precedence documentation could be more clear

New submission from Aidan Feldman : 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