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: Improve Python Language Reference based on [Köhl 2020]
Type: Stage:
Components: Versions:
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: JelleZijlstra, brandtbucher, corona10, gvanrossum
Priority: normal Keywords:

Created on 2022-02-15 01:19 by gvanrossum, last changed 2022-04-11 14:59 by admin.

Messages (4)
msg413275 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2022-02-15 01:19
In https://arxiv.org/pdf/2109.03139.pdf ("M Köhl, An Executable Structural Operational Formal Semantics for Python, Master Thesis 2020 Saarland University) there are some observations on cases where the Language Reference (referred to as PLR) is ambiguous or incorrect.

Somebody should go over the thesis, collect the issues, and then we can update the language reference.

See also https://github.com/faster-cpython/ideas/issues/208#issuecomment-1039612432
msg413863 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2022-02-23 21:53
A few examples of issues brought up by Kohl:

- While the PLR explicitly states that “x < y calls x.__lt__(y)”
  [20, §3.3.1.] this is actually false.
  There are cases where x < y does not call x.__lt__(y)
  and there are other cases where x.__lt__(y) is called
  but more than that happens.

- If no expression is provided, the PLR states that
  “the last exception that was active in the current scope”
  should be re-raised. Unfortunately, the PLR stays
  unspecific on what it means for an exception to be
  “the last exception that was active in the current scope.
  [...]
  Instead, raise re-raises the exception that *is active*
  in the respective execution context

(Perhaps unrelated, but indicative of how out of date the PLR is: in executionmodel.rst there's still a mention of and even an index entry for restricted execution, a feature that was removed in some early Python 2 release.)
msg413865 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2022-02-23 23:07
Another:

- The description of this name binding and resolution process
  in the PLR [20, §4.2.] is unfortunately not particularly clear.

(I found this to be the case too, and wrote up what I found:
https://gvanrossum.github.io/formal/scopesblog.html
Hopefully it matches what Kohl derived.)
msg413873 - (view) Author: Jelle Zijlstra (JelleZijlstra) * (Python committer) Date: 2022-02-24 02:16
Some specific points from the document:

"While the PLR explicitly states that “x < y calls x.__lt__(y)” [20, 3.3.1.] this is actually false." They had to read the implementation to actually figure out how this works.

"If no expression is provided, the PLR states that “the last exception that was active in the current scope” should be re-raised. Unfortunately, the PLR stays unspecific on what it means for an exception to be “the last exception that was active in the current scope.”"

"The description of this name binding and resolution process in the PLR [20, 4.2.] is unfortunately not particularly clear"

"While generator objects seem not to be specified as part of the PLR, the documentation of the inspect module5 describes them."

(I didn't read the whole thing, but searched for "PLR".)

Here's a few similar things I noticed while reading through the reference recently:

- https://docs.python.org/3.10/reference/datamodel.html#the-standard-type-hierarchy is supposed to be a list of primitive types but has a few problems:
  - Lists "numbers.Number" as a standard type, when it's an ABC that's really not part of the core language
  - Lists "I/O objects" as a kind of standard object, but there are many kinds of file-like objects, and I'd argue they're not part of the core language, but of the standard library.
  - On the other hand, some builtin types (range, map, filter, zip) are not listed.
- https://docs.python.org/3.10/reference/expressions.html#subscriptions doesn't actually give the rules about when __class_getitem__ is called vs. __getitem__. That's in https://docs.python.org/3.10/reference/datamodel.html#class-getitem-versus-getitem.
- The text at https://docs.python.org/3.10/reference/expressions.html#calls doesn't cover positional-only parameters.
History
Date User Action Args
2022-04-11 14:59:56adminsetgithub: 90910
2022-02-24 02:16:35JelleZijlstrasetnosy: + JelleZijlstra
messages: + msg413873
2022-02-23 23:07:02gvanrossumsetmessages: + msg413865
2022-02-23 21:53:16gvanrossumsetmessages: + msg413863
2022-02-23 18:58:31brandtbuchersetnosy: + brandtbucher
2022-02-23 16:16:21corona10setnosy: + corona10
2022-02-19 02:24:40AlexWaygoodsetkeywords: - patch
nosy: - AlexWaygood

stage: patch review ->
2022-02-19 02:24:19AlexWaygoodsetpull_requests: - pull_request29560
2022-02-19 02:21:14AlexWaygoodsetkeywords: + patch
nosy: + AlexWaygood

pull_requests: + pull_request29560
stage: patch review
2022-02-15 01:19:11gvanrossumcreate