Mailman 3 February 2021 - docs

[issue42982] Update suggested number of iterations for pbkdf2_hmac()
by Illia Volochii Feb. 7, 2021

Feb. 7, 2021

New submission from Illia Volochii <illia.volochii(a)gmail.com>: Documentation [1] suggests using at least 100,000 iterations of SHA-256 as of 2013. Currently, it is 2021, and it is common to use much more iterations. For example, Django will use 260,000 by default in the next 3.2 LTS release and 320,000 in 4.0 [2][3]. I suggest suggesting at least 250,000 iterations that is a somewhat round number close to the one used by modern libraries. [1] https://docs.python.org/3/library/hashlib.html#hashlib.pbkdf2_hmac [2] https://github.com/django/django/commit/f2187a227f7a3c80282658e699ae9b04023… [3] https://github.com/django/django/commit/a948d9df394aafded78d72b1daa785a0abf… ---------- assignee: docs@python components: Documentation messages: 385365 nosy: docs@python, illia-v priority: normal severity: normal status: open title: Update suggested number of iterations for pbkdf2_hmac() _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue42982> _______________________________________

3 7

[issue16781] execfile/exec execution in other than global scope uses locals(), leading to undefined behavior
by Terry J. Reedy Feb. 7, 2021

Feb. 7, 2021

Terry J. Reedy <tjreedy(a)udel.edu> added the comment: New changeset 863eb7170b3017399fb2b786a1e3feb6457e54c2 by Miss Islington (bot) in branch '3.9': bpo-16781: In 'exec' doc, add 'nonlocal' to 'yield' and 'return' (GH-2446) https://github.com/python/cpython/commit/863eb7170b3017399fb2b786a1e3feb645… ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue16781> _______________________________________

1 0

[issue16781] execfile/exec execution in other than global scope uses locals(), leading to undefined behavior
by miss-islington Feb. 7, 2021

Feb. 7, 2021

miss-islington <mariatta.wijaya+miss-islington(a)gmail.com> added the comment: New changeset 920bf6a3a656e329c2bcbb761eb8c13c46c8cd05 by Miss Islington (bot) in branch '3.8': bpo-16781: In 'exec' doc, add 'nonlocal' to 'yield' and 'return' (GH-2446) https://github.com/python/cpython/commit/920bf6a3a656e329c2bcbb761eb8c13c46… ---------- nosy: +miss-islington _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue16781> _______________________________________

1 0

[issue16781] execfile/exec execution in other than global scope uses locals(), leading to undefined behavior
by Terry J. Reedy Feb. 7, 2021

Feb. 7, 2021

Terry J. Reedy <tjreedy(a)udel.edu> added the comment: PR is based on 'Note:...' directly above. I am still thinking about a patch for the namespace paragraph. ---------- nosy: -miss-islington stage: patch review -> needs patch _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue16781> _______________________________________

1 0

[issue16781] execfile/exec execution in other than global scope uses locals(), leading to undefined behavior
by miss-islington Feb. 7, 2021

Feb. 7, 2021

Change by miss-islington <mariatta.wijaya+miss-islington(a)gmail.com>: ---------- pull_requests: +23265 pull_request: https://github.com/python/cpython/pull/24471 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue16781> _______________________________________

1 0

[issue16781] execfile/exec execution in other than global scope uses locals(), leading to undefined behavior
by miss-islington Feb. 7, 2021

Feb. 7, 2021

Change by miss-islington <mariatta.wijaya+miss-islington(a)gmail.com>: ---------- nosy: +miss-islington nosy_count: 6.0 -> 7.0 pull_requests: +23264 pull_request: https://github.com/python/cpython/pull/24470 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue16781> _______________________________________

1 0

[issue16781] execfile/exec execution in other than global scope uses locals(), leading to undefined behavior
by Terry J. Reedy Feb. 7, 2021

Feb. 7, 2021

Terry J. Reedy <tjreedy(a)udel.edu> added the comment: New changeset 0ec57e25c918b859b9f8d464e34e0ac859c2f8b3 by Terry Jan Reedy in branch 'master': bpo-16781: In 'exec' doc, add 'nonlocal' to 'yield' and 'return' (GH-2446) https://github.com/python/cpython/commit/0ec57e25c918b859b9f8d464e34e0ac859… ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue16781> _______________________________________

1 0

[issue16781] execfile/exec execution in other than global scope uses locals(), leading to undefined behavior
by Terry J. Reedy Feb. 6, 2021

Feb. 6, 2021

Change by Terry J. Reedy <tjreedy(a)udel.edu>: ---------- keywords: +patch pull_requests: +23263 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/24469 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue16781> _______________________________________

1 0

[issue43138] [doc] Inconsistent / confusing documentation regarding importing submodules
by Dirk Herrmann Feb. 5, 2021

Feb. 5, 2021

New submission from Dirk Herrmann <dirk.herrmann-privat(a)gmx.de>: In the language reference, section "7.11 The import statement" is is explained in the example section: import foo.bar.baz # foo.bar.baz imported, foo bound locally When looking at "5.3. Searching", it is stated that regarding foo.bar.baz: In this case, Python first tries to import foo, then foo.bar, and finally foo.bar.baz. I find this confusing. Assuming that 5.3 is correct, the examples in 7.11 could be improved, like, for the sample line mentioned above: import foo.bar.baz # foo, foo.bar and foo.bar.baz imported, foo bound locally ---------- assignee: docs@python components: Documentation messages: 386532 nosy: Dirk Herrmann, docs@python priority: normal severity: normal status: open title: [doc] Inconsistent / confusing documentation regarding importing submodules type: enhancement versions: Python 3.10 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue43138> _______________________________________

1 0

[issue35295] Please clarify whether PyUnicode_AsUTF8AndSize() or PyUnicode_AsUTF8String() is preferred
by Marcin Kowalczyk Feb. 5, 2021

Feb. 5, 2021

New submission from Marcin Kowalczyk <qrczakmk(a)gmail.com>: The documentation is silent whether PyUnicode_AsUTF8AndSize() or PyUnicode_AsUTF8String() is preferred. We are under the assumption that both are acceptable for the given caller, i.e. the caller wants to access just the sequence of UTF-8 code units (e.g. for calling a C++ function which takes std::string_view or std::string as a parameter), and the caller either will copy the UTF-8 code units immediately or is willing to own a temporary object to ensure a lifetime of the UTF-8 code units. File comments in unicodeobject.h about PyUnicode_AsUTF8AndSize() have a warning: *** This API is for interpreter INTERNAL USE ONLY and will likely *** be removed or changed in the future. *** If you need to access the Unicode object as UTF-8 bytes string, *** please use PyUnicode_AsUTF8String() instead. The discrepancy between these comments and the documentation should be fixed. Either the documentation is correct and the comment is outdated, or the comment is correct and the documentation is lacking guidance. It is not even clear which function is better technically: - PyUnicode_AsUTF8String() always allocates the string. PyUnicode_AsUTF8AndSize() does not allocate the string if the unicode object is ASCII-only (this is common) or if PyUnicode_AsUTF8AndSize() was already called before. - If conversion must be performed, then PyUnicode_AsUTF8String() makes a single allocation, while PyUnicode_AsUTF8AndSize() first calls PyUnicode_AsUTF8String() and then copies the string. - If the string is converted multiple times, then PyUnicode_AsUTF8AndSize() caches the result - faster. If the string is converted once, then the result persists as long as the string persists - wastes memory. I see the following possible resolutions: 1a. Declare both functions equally acceptable. Remove comments claiming that PyUnicode_AsUTF8AndSize() should be avoided. 1b. 1a, and change the implementation of PyUnicode_AsUTF8AndSize() to avoid allocating the string twice if it needs to be materialized, so that PyUnicode_AsUTF8AndSize() is never significantly slower than PyUnicode_AsUTF8String(). 2a. Declare PyUnicode_AsUTF8String() preferred. Indicate this in the documentation. 2b. 2a, and provide a public interface to check and access UTF-8 code units without allocating a new string in case this is possible (I think PyUnicode_READY() + PyUnicode_IS_ASCII() + PyUnicode_DATA() + PyUnicode_GET_LENGTH() would work, but they are not documented; or possibly also check if the string has a cached UTF-8 representation without populating that cached representation), so that a combination of the check with PyUnicode_AsUTF8String() is rarely or never significantly slower than PyUnicode_AsUTF8AndSize(). ---------- assignee: docs@python components: Documentation, Interpreter Core, Unicode messages: 330249 nosy: Marcin Kowalczyk, docs@python, ezio.melotti, vstinner priority: normal severity: normal status: open title: Please clarify whether PyUnicode_AsUTF8AndSize() or PyUnicode_AsUTF8String() is preferred type: performance versions: Python 3.8 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue35295> _______________________________________

4 9