Mailman 3 November 2021 - Docs-bugs

[issue1635741] Py_Finalize() doesn't clear all Python objects at exit
by Erlend E. Aasland Nov. 4, 2021

Nov. 4, 2021

Change by Erlend E. Aasland <erlend.aasland(a)innova.no>: ---------- Removed message: https://bugs.python.org/msg405698 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue1635741> _______________________________________

1 0

[issue1635741] Py_Finalize() doesn't clear all Python objects at exit
by Ahmed Sayeed Nov. 4, 2021

Nov. 4, 2021

Ahmed Sayeed <ahmedsayeed1982(a)yahoo.com> added the comment: Possibly similar to 23220 however on 64-bit recent Debian sid with trivial code I see : https://www.webb-dev.co.uk/category/crypto/ mimas$ mimas$ uname -a http://www.compilatori.com/category/services/ Linux mimas 5.10.0-6-sparc64 #1 Debian 5.10.28-1 (2021-04-09) sparc64 GNU/Linux mimas$ http://www.acpirateradio.co.uk/category/services/ mimas$ mimas$ /usr/bin/gcc --version http://www.logoarts.co.uk/category/services/ gcc (Debian 10.2.1-6) 10.2.1 20210110 Copyright (C) 2020 Free Software Foundation, Inc. http://www.mconstantine.co.uk/crypto/kilimanjaro/ This is free software; see the source for copying conditions. There is NO http://www.slipstone.co.uk/category/services/ warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. mimas$ http://embermanchester.uk/category/services/ mimas$ mimas$ cat -n foo.c http://connstr.net/category/services/ 1 2 #include <stdio.h> 3 #include <stdlib.h> 4 http://joerg.li/category/services/ 5 int main(int argc, char **argv) 6 { 7 int a = 1; 8 http://www.jopspeech.com/category/services/ 9 printf("a = %i\n", a); 10 http://www.wearelondonmade.com/category/services/ 11 printf("&a = %p\n", &a); 12 13 return EXIT_SUCCESS; 14 https://waytowhatsnext.com/category/crypto/ 15 } 16 mimas$ http://www.iu-bloomington.com/category/crypto/ mimas$ mimas$ /usr/bin/gcc -std=iso9899:1999 -pedantic -pedantic-errors -fno-builtin https://komiya-dental.com/category/crypto/ -g -m64 -O0 -mno-app-regs -mcpu=ultrasparc -mmemory-model=tso -o foo foo.c mimas$ http://www-look-4.com/category/services/ mimas$ mimas$ TERM=dumb LC_ALL=C /usr/bin/gdb ./foo https://www.mktrade.fi/ruiskuvalu GNU gdb (Debian 10.1-2) 10.1.90.20210103-git g -m64 -O0 -mno-app-regs -mcpu=ultrasparc -mmemory-model=tso -o http://www.go-mk-websites.co.uk/crypto/namibia/ foo foo. g -m64 -O0 -mno-app-regs -mcpu=ultrasparc -mmemory-model=tso http://fishingnewsletters.co.uk/services/camping-equipment/ -o foo foo. g -m64 -O0 -mno-app-regs -mcpu=ultrasparc -mmemory-model=tso -o foo foo. ---------- assignee: -> docs@python components: +Documentation -Interpreter Core, Subinterpreters nosy: +ahmedsayeed1982, docs@python -Jim Fasarakis-Hilliard, TCsaba, amaury.forgeotdarc, christian.heimes, corona10, eric.snow, erlendaasland, h-vetinari, isoschiz, koubaa, kylotan, lukasz.langa, miss-islington, orsenthil, pconnell, petr.viktorin, phsilva, python-dev, santoso.wijaya, serhiy.storchaka, serhiy.storchaka, shihai1991, tlesher, vstinner, ysj.ray versions: +Python 3.6 -Python 3.10 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue1635741> _______________________________________

1 0

[issue45633] Py_GT listed twice in Doc/extending/newtypes.rst
by Julien Palard Nov. 3, 2021

Nov. 3, 2021

New submission from Julien Palard <julien+python(a)palard.fr>: In Doc/extending/newtypes one can read: > This function is called with two Python objects and the operator as arguments, where the operator is one of Py_EQ, Py_NE, Py_LE, Py_GT, Py_LT or Py_GT. It bet one of them should be Py_GE. (I let this one as an easy first contrib.) ---------- assignee: docs@python components: Documentation keywords: easy messages: 405119 nosy: docs@python, mdk priority: normal severity: normal status: open title: Py_GT listed twice in Doc/extending/newtypes.rst _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue45633> _______________________________________

5 8

[issue45646] The documentation wrongly uses or_expr for star expresion in displays
by Arthur Milchior Nov. 2, 2021

Nov. 2, 2021

New submission from Arthur Milchior <arthur(a)milchior.fr>: According to the current documentation, I believe there is an error in list_display, set_display and dict_display. According to list display, this is a valid expression [* l1 ^ l2] parsed as list_display: "[" starred_list: starred_item: "*" or_expr: xor_expr: xor_expr: "l1" "^" and_expr: "l2" "]" I add the full derivation from and_expr to l2 at the end of the report, it's not important for this topic. The same issue is present for set. For dictionary it is also present, but instead the error is in key_datum. I have no idea what would be the proper correction. Indeed [*l1+l2] is valid (in 3.9) at least. So it's not like the element after a star is restricted to be an atom. At the very least, I believe it should be clearly indicated that, contrary to what the name indicates, "or_expr" do not mean that we accept any or, nor any expression. It just mean that *some_complex_expression is interpreted as * (some_complex_expression) and that it is valid iff some_complex_expression is valid shift_expr: a_expr: m_expr: power: primary: atom: identifier: "l2" ---------- assignee: docs@python components: Documentation messages: 405187 nosy: Arthur-Milchior, docs@python priority: normal severity: normal status: open title: The documentation wrongly uses or_expr for star expresion in displays versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue45646> _______________________________________

3 8

[issue45647] "expression" is erroneous in the doc
by Arthur Milchior Nov. 2, 2021

Nov. 2, 2021

New submission from Arthur Milchior <arthur(a)milchior.fr>: https://docs.python.org/3/reference/expressions.html#grammar-token-python-g… is wrong This line state: `expression ::= conditional_expression | lambda_expr` and it is a problem because, by the way sphinx understand reference, this mean that any people who use the token `expression` will be linked to this particular line. For example in https://docs.python.org/3/reference/expressions.html#grammar-token-python-g… `key_datum ::= expression ":" expression | "**" or_expr` while clearly a key_datum is not expecting only a conditional expression or a lambda expression. Admittedly, you can derive, from expression: * conditional_expression * or_test * and_test * not_test * comparison * or_expr * xor_expr * and_expr * shift_expr * a_expr * m_expr * u_expr * power * primary * atom in this order, so in practice you can probably derive most of the expressions. However, I doubt that this is what the documentation meant here, and clearly not practical. ---------- assignee: docs@python components: Documentation messages: 405189 nosy: Arthur-Milchior, docs@python priority: normal severity: normal status: open title: "expression" is erroneous in the doc versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue45647> _______________________________________

2 1

[issue45602] The grammar misses links that are present everywhere else
by Arthur Milchior Nov. 1, 2021

Nov. 1, 2021

New submission from Arthur Milchior <arthur(a)milchior.fr>: The grammar, in https://docs.python.org/3/reference/grammar.html , lacks some utilities that the remaining of the documentation have. While it remains usable, it is hard to navigate. As an example https://www.python.org/dev/peps/pep-0634/ 's "star_named_exrpsession" and "block" links to the general grammar page, and indeed can't link to the specific rules as there are no anchor on them. This would also allow a related improvement: being able to click on a rule R in the right side of a declaration and go to the definition of R. Given the recursive nature of grammar, that would transform a sequence of search into a sequence of click (and even allow to use the browser's "back" to go back to the previous definition, or to open the new definition in a new tab) As far as I can tell, the first action would be to add a new kind of token on Doc/tools/extensions/peg_highlight.py , so that we distinguish the left and the right part of the rule. The left part (the name of the declared rule) would be easy to recognize as it always start on the beginning of the line and end with :. The second action would be that, for each declaration D, the html would contain an anchor "#D". And each time D would appear on the right hand side of a rule, it would be in a link to #D I suspect that adding those links and anchor could be done by overriding the default formatter or highlighter, but I don't understand pygment well enough to know what should be done here ---------- assignee: docs@python components: Documentation messages: 404946 nosy: Arthur-Milchior, docs@python priority: normal severity: normal status: open title: The grammar misses links that are present everywhere else type: enhancement versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue45602> _______________________________________

2 1