Repository navigation
Improve Python Language Reference based on [Köhl 2020] #90910
Description
| BPO | 46754 |
|---|---|
| Nosy | @gvanrossum, @JelleZijlstra, @corona10, @brandtbucher |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2022-02-15.01:19:11.536>
labels = []
title = 'Improve Python Language Reference based on [K\xc3\xb6hl 2020]'
updated_at = <Date 2022-02-24.02:16:35.889>
user = 'https://github.com/gvanrossum'bugs.python.org fields:
activity = <Date 2022-02-24.02:16:35.889>
actor = 'JelleZijlstra'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = []
creation = <Date 2022-02-15.01:19:11.536>
creator = 'gvanrossum'
dependencies = []
files = []
hgrepos = []
issue_num = 46754
keywords = []
message_count = 4.0
messages = ['413275', '413863', '413865', '413873']
nosy_count = 4.0
nosy_names = ['gvanrossum', 'JelleZijlstra', 'corona10', 'brandtbucher']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = None
url = 'https://bugs.python.org/issue46754'
versions = []
Activity
gvanrossum commentedon Feb 15, 2022
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 faster-cpython/ideas#208 (comment)
gvanrossum commentedon Feb 23, 2022
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.)
gvanrossum commentedon Feb 23, 2022
Another:
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.)
JelleZijlstra commentedon Feb 24, 2022
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:
gvanrossum commentedon Mar 19, 2024
Is anyone interested in picking this up? The best approach is probably making one or a few small improvements at a time and getting several (many?) small docs PRs merged.