-
-
Notifications
You must be signed in to change notification settings - Fork 31.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
help() on operator precedence has confusing entries "await" "x" and "not" "x" #89556
Comments
Nobody seems to have noticed this AFAICS: "not" "x" That looks as if there were two operators, "not" and "x". But the letter x is just an argument to the operator, so it should be: "not x" exactly as for "+x" and "-x" and "~x" and "x[index]" and "x.attribute", where also x is not part of the operator but an argument. On the corresponding web page https://docs.python.org/3/reference/expressions.html#operator-summary |
Thanks for fixing the typo, didn't knnow how to do that when I spotted it (I'm new to this).
You also removed Python version 3.6, 3.7, 3.8, however, I just tested on pythonanywhere,
>>> sys.version
'3.7.0 (default, Aug 22 2018, 20:50:05) \n[GCC 5.4.0 20160609]'
So I can confirm that the bug *is* there on 3.7 (so I put this back in the list - unless it was removed in a later 3.7.x (to you mean that?) and put back in later versions...?)
It is also on the Python 3.9.7 I'm running on my laptop, so I'd greatly be surprised if it were not present on the other two versions you also removed. |
I guess those old versions were removed because they are "frozen", that is, not receiving doc fixes anymore. |
Correct; 3.7 and 3.8 are both in security-fix-only maintenance mode; their documentation is no longer updated unless a security-related fix causes a significant change in behavior that needs to be documented. As far as fixing this issue, we have a few options. The cause is that the source for these rows looks like ':keyword:`await` ``x``', which basically produces two inline code blocks with a non-code space between, which the pydoc-topics renderer renders as two separately quoted words. Option 1: Replace ':keyword:`await` ``x``' with `:keyword:`await x <await>`. This keeps the link to the `await` anchor, but extends it across the ' x' bit. The pydoc rendering is '"await x"'. Option 2: Replace ':keyword:`await` ``x``' with '``await x``. This also gives the pydoc rendering of '"await x"', but loses the link to the `await` anchor, which I would rather not do. Option 3: As option 2, but also replace 'Await' in the description column with a link to the Option 4: Adjust the pydoc-topics renderer to smush together consecutive inline code blocks. This might cause some issues elsewhere. |
option 1 looks most attractive to me (and will also look most attractive in the rendering, IMHO -- certainly better than "await" "x", in any case). P.S.: OK, thanks for explanations concerning 3.6 - 3.8. I do understand that it won't be fixed for these versions (not certain why not if possible at no cost), but I do not understand why these labels must be removed. The bug does exist but should simply be considered as "nofix" for these versions (or not), given that it's not in the "security" category. The fact that it won't be fixed, for whatever reason, should not mean that it should not be listed as existing, there. |
In past we could backport some simple documentation fixes to security-only branches. But currently only the release manager of the corresponded version has permission to commit to these branches, and we do not want to disturb them for such minor cause. I concur with analysis of Zachary. All options look good to me. |
I have created a patch for this issue. |
This is now fixed, thanks Zackery! |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: