Mailman 3 May 2021 - docs

[issue38291] Unclear status of the typing.io and typing.re pseudo-modules in docs and runtime
by dgelessus 03 May '21

03 May '21

New submission from dgelessus <dgelessus+bugs.python.org(a)me.com>: According to bpo-35089 (and the GitHub issues linked there), the typing.io and typing.re modules should no longer be used. Starting with Python 3.6, the typing documentation no longer mentions the typing.io and typing.re modules, and instead documents their contents as part of the main typing module. However, the typing module at runtime still supports typing.io and typing.re as before. Since these modules are not meant to be used anymore and are no longer documented, I would expect at least a DeprecationWarning when using them at runtime. The documentation on this could also be a bit clearer. As long as the modules are still supported at runtime, I would expect the documentation to mention that they still exist, but shouldn't be used anymore. In its current state, the documentation is confusing when coming from Python 3.5 (where typing.io and typing.re were the only documented way to access IO, Pattern, etc., but accessing typing.IO and typing.Pattern directly also works at runtime). ---------- assignee: docs@python components: Documentation, Library (Lib) messages: 353356 nosy: dgelessus, docs@python priority: normal severity: normal status: open title: Unclear status of the typing.io and typing.re pseudo-modules in docs and runtime type: behavior versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue38291> _______________________________________

4 3

[issue32752] no information about accessing typing.Generic type arguments
by Paul Pinterits 02 May '21

02 May '21

New submission from Paul Pinterits <rawing7(a)gmail.com>: The documentation of the typing module explains how to instantiate generic types, but there is no information about how to extract the type arguments from a generic type. Example: >>> list_of_ints = typing.List[int] >>> >>> # how do we get <class 'int'> out of list_of_ints? >>> list_of_ints.??? <class 'int'> Through trial and error I've discovered list_of_ints.__args__, which *seems* to be what I'm looking for, but since it's never mentioned in the docs, it's unclear whether this __args__ attribute is an implementation detail or not. Please document the official/intended way to extract type arguments from a Generic. ---------- assignee: docs@python components: Documentation messages: 311520 nosy: Paul Pinterits, docs@python priority: normal severity: normal status: open title: no information about accessing typing.Generic type arguments type: enhancement versions: Python 3.5, Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue32752> _______________________________________

6 6

[issue41411] Improve and consolidate f-strings docs
by Ezio Melotti 02 May '21

02 May '21

New submission from Ezio Melotti <ezio.melotti(a)gmail.com>: [Creating a new issue from #41045] I was just just trying to link to someone the documentation for f-strings, but: 1) Searching "fstring" only returns two results about xdrlib[0]; 2) Searching "f-string" returns many unrelated results[1]; 3) The first (and closer) result (string -- Common string operations[2]) yields nothing while using ctrl+f with fstring, f-string, f', f"; 4) at the top of that page there are two links in a "see also": * Text Sequence Type — str[3]: it mentions raw strings at the beginning, but also yields no results for fstring, f-string, f', f"; * String Methods[4]: that is another section of the previous page (so ctrl+f doesn't find anything), but has a link to "Format String Syntax"[5]; 5) The "Format String Syntax" page[5] has another link in the middle of a paragraph that points to "formatted string literals", that eventually brings us to the right page[6]; 6) the "right page"[6] has a wall of text with a block of code containing the grammar, luckily followed by a few examples. I think we should: 1) add index entries for "f-string" and "fstring" in the relevant sections of the docs, so that they appear in the search result; 2) in the Text Sequence Type — str[3] section, have a bullet list for f-strings, raw-strings, and possibly u-strings; 3) possibly use the term "f-string" in addition (or instead) of "formatted string literal", to make the pages more ctrl+f-friendly throughout the docs; 4) possibly have another more newbie-friendly section on f-string (compared to the lexical analysis page) in the tutorial, in the stdtypes page[7] (e.g. before the printf-style String Formatting" section[8]), or in the string page[2] (e.g. after the "Format String Syntax" section[10]); 5) possibly reorganize and consolidate the different sections about strings, string methods, str.format(), the format mini-language, f-strings, raw/unicode-strings, %-style formatting in a single page or two (a page for the docs and one for the grammar), since it seems to me that over the years these sections got a bit scattered around as they were being added. [0]: https://docs.python.org/3/search.html?q=fstring [1]: https://docs.python.org/3/search.html?q=f-string [2]: https://docs.python.org/3/library/string.html [3]: https://docs.python.org/3/library/stdtypes.html#textseq [4]: https://docs.python.org/3/library/stdtypes.html#string-methods [5]: https://docs.python.org/3/library/string.html#formatstrings [6]: https://docs.python.org/3/reference/lexical_analysis.html#f-strings [7]: https://docs.python.org/3/library/stdtypes.html [8]: https://docs.python.org/3/library/stdtypes.html#printf-style-string-formatt… ---------- assignee: docs@python components: Documentation messages: 374398 nosy: docs@python, eric.smith, ezio.melotti priority: normal severity: normal stage: needs patch status: open title: Improve and consolidate f-strings docs type: enhancement versions: Python 3.10, Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue41411> _______________________________________

6 13

[issue43997] dataclasses documentation needs version added for match_args, kw_only, and slots
by miss-islington 02 May '21

02 May '21

New submission from miss-islington <mariatta.wijaya+miss-islington(a)gmail.com>: New changeset a5eabc9a39c617475adb7eaee62de7566a995442 by Shreyan Avigyan in branch 'master': bpo-43997: Add versionadded directives for to match_args, kw_only, and slots in dataclasses.dataclasses documentation (GH-25803) https://github.com/python/cpython/commit/a5eabc9a39c617475adb7eaee62de7566a… ---------- nosy: +miss-islington _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue43997> _______________________________________

2 1

[issue36384] [security] CVE-2021-29921: ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal
by Christian Heimes 02 May '21

02 May '21

Christian Heimes <lists(a)cheimes.de> added the comment: Łukasz, thanks for pushing the PR over the finish line! ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36384> _______________________________________

1 0

[issue36384] [security] CVE-2021-29921: ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal
by Łukasz Langa 02 May '21

02 May '21

Łukasz Langa <lukasz(a)langa.pl> added the comment: New changeset 5374fbc31446364bf5f12e5ab88c5493c35eaf04 by Miss Islington (bot) in branch '3.9': bpo-36384: Leading zeros in IPv4 addresses are no longer tolerated (GH-25099) (GH-25815) https://github.com/python/cpython/commit/5374fbc31446364bf5f12e5ab88c5493c3… ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36384> _______________________________________

1 0

[issue36384] [security] CVE-2021-29921: ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal
by Łukasz Langa 02 May '21

02 May '21

Łukasz Langa <lukasz(a)langa.pl> added the comment: New changeset 60ce8f0be6354ad565393ab449d8de5d713f35bc by Christian Heimes in branch 'master': bpo-36384: Leading zeros in IPv4 addresses are no longer tolerated (GH-25099) https://github.com/python/cpython/commit/60ce8f0be6354ad565393ab449d8de5d71… ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36384> _______________________________________

1 0

[issue36384] [security] CVE-2021-29921: ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal
by miss-islington 02 May '21

02 May '21

Change by miss-islington <mariatta.wijaya+miss-islington(a)gmail.com>: ---------- nosy: +miss-islington nosy_count: 14.0 -> 15.0 pull_requests: +24501 pull_request: https://github.com/python/cpython/pull/25815 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36384> _______________________________________

1 0

[issue36384] [security] CVE-2021-29921: ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal
by Łukasz Langa 02 May '21

02 May '21

Change by Łukasz Langa <lukasz(a)langa.pl>: ---------- versions: -Python 3.8 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36384> _______________________________________

1 0

[issue36384] [security] CVE-2021-29921: ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal
by Łukasz Langa 02 May '21

02 May '21

Łukasz Langa <lukasz(a)langa.pl> added the comment: Due to the relative obscurity of the bug and potential disruption of the fix, I decided not to include it in 3.8. However, Michał's argument about 3.10 not being released for another five months is resonating with me and so we will be backporting the change to 3.9.5, to be released tomorrow. Victor's argument about opt-ins being a bad way to fix security also makes sense, although let me point out that we've made decisions the other way in the past as well, for instance with hash randomization. In any case, the issue will be solved in Python 3.10.0 Beta 1 and Python 3.9.5. Having the fixed behavior "in 3.9.5 and newer" makes for easy mechanical checks whether a given version is affected. ---------- assignee: docs@python -> _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36384> _______________________________________

1 0