Mailman 3 June 2018 - docs

[issue24937] Multiple problems in getters & setters in capsulethunk.h
by Petr Viktorin Sept. 24, 2018

Sept. 24, 2018

New submission from Petr Viktorin: In https://docs.python.org/3/howto/cporting.html#cobject-replaced-with-capsule (added in issue13053): 1) __PyCapsule_GetField is defined as:: #define __PyCapsule_GetField(capsule, field, default_value) ... but called as:: __PyCapsule_GetField(capsule, field) 2) __PyCapsule_SetField returns the wrong value (1 for success, 0 for failure). 3) Both the getter and setter don't set the exception on failure, leading to "SystemError: error return without exception set". Here's a patch. ---------- assignee: docs@python components: Documentation files: capsulethunk.patch keywords: patch messages: 249138 nosy: docs@python, encukou, larry, ncoghlan priority: normal severity: normal status: open title: Multiple problems in getters & setters in capsulethunk.h versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file40256/capsulethunk.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue24937> _______________________________________

3 11

[issue31737] Documentation renders incorrectly
by Richard Gibson Sept. 22, 2018

Sept. 22, 2018

New submission from Richard Gibson <richard.gibson(a)gmail.com>: The content at docs.python.org seems to be inserting language-dependent "smart quotes" in code blocks, which mangles backslashes and sequences like `'''`. Observed at https://docs.python.org/3/reference/lexical_analysis.html#string-and-bytes-… , which renders longstring ::= “”’” longstringitem* “”’” | ‘”“”’ longstringitem* ‘”“”’ instead of longstring ::= "'''" longstringitem* "'''" | '"""' longstringitem* '"""' and stringescapeseq ::= “" <any source character> instead of stringescapeseq ::= "\" <any source character> , and looks even worse in other languages: longstring ::= » »” » longstringitem* » »” » | “ »« »” longstringitem* “ »« »” longstring ::= 「」』」 longstringitem* 「」』」 | 『」「」』 longstringitem* 『」「」』 Running `make html` locally produces the desired output, so whatever's going on appears specific to the public site. ---------- assignee: docs@python components: Documentation messages: 303988 nosy: docs@python, gibson042 priority: normal severity: normal status: open title: Documentation renders incorrectly versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue31737> _______________________________________

4 5

[issue30350] devguide suggests to use VS 2008 to build Python 2.7, but VS 2008 is no more supported?
by STINNER Victor Sept. 22, 2018

Sept. 22, 2018

New submission from STINNER Victor: Steve Dower wrote this comment on my PR https://github.com/python/cpython/pull/1544 : "Ah, I see. This is fine then - I have very little interest in doing much work to support the old build files (as they are explicitly unsupported)." Copy of my reply: "I have very little interest in doing much work to support the old build files (as they are explicitly unsupported)." Wait wait wait... I fail to follow progress on the Windows build system, so I rely on the devguide which I expect to be up to date, and the guide says: https://docs.python.org/devguide/setup.html#windows-compiling "Python 2.7 uses Microsoft Visual Studio 2008, which is most easily obtained through an MSDN subscription." I have a MSDN account, but after 30 min, I failed to get my MSDN number and I don't know my subscription is still valid or not (well, I guess that, it's expired). It took me 1 hour to find an old ISO of Visual Studio 2008, and not from microsoft.com :-( I didn't want to install VS 2008, but I just followed the devguide. ... Do you mean that VS 2010 must now be used and the devguide is just outdated? Moreover: we do have a buildbot using VS 2008. I'm now trying to fix all buildbots, so I had to fix issues on this VS 2008 buildbot too: http://bugs.python.org/issue30313 But I guess that it's ok to have a buildbot on a system not officially fully supported. ---------- assignee: docs@python components: Build, Documentation, Windows messages: 293536 nosy: docs@python, haypo, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: devguide suggests to use VS 2008 to build Python 2.7, but VS 2008 is no more supported? versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue30350> _______________________________________

5 12

[issue29013] zipfile: inconsistent doc for ZIP64 file size
by Monte Davidoff Sept. 21, 2018

Sept. 21, 2018

New submission from Monte Davidoff: The documentation for the zipfile module, https://docs.python.org/3.5/library/zipfile.html, contains inconsistent descriptions of the maximum size of a ZIP file when allowZip64 is False. The second paragraph in the zipfile module documentation states: "It can handle ZIP files that use the ZIP64 extensions (that is ZIP files that are more than 4 GiB in size)." Later on, in the description of the zipfile.ZipFile class, it says: "If allowZip64 is True (the default) zipfile will create ZIP files that use the ZIP64 extensions when the zipfile is larger than 2 GiB." The two sizes (4 GiB and 2 GiB) should be the same. According to https://en.wikipedia.org/wiki/Zip_(file_format)#ZIP64, 4 GiB is the correct value. There is a similar problem in the 2.7.13 documentation, https://docs.python.org/2.7/library/zipfile.html. ---------- assignee: docs@python components: Documentation messages: 283597 nosy: docs@python, mndavidoff priority: normal severity: normal status: open title: zipfile: inconsistent doc for ZIP64 file size versions: Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue29013> _______________________________________

4 9

[issue19431] Document PyFrame_FastToLocals() and PyFrame_FastToLocalsWithError()
by STINNER Victor Sept. 20, 2018

Sept. 20, 2018

New submission from STINNER Victor: (Copy of an email) Georg Brandl via python.org Am 29.10.2013 01:19, schrieb victor.stinner: > http://hg.python.org/cpython/rev/4ef4578db38a > changeset: 86715:4ef4578db38a > user: Victor Stinner <victor.stinner(a)gmail.com> > date: Tue Oct 29 01:19:37 2013 +0100 > summary: > Issue #18408: Add a new PyFrame_FastToLocalsWithError() function to handle > exceptions when merging fast locals into f_locals of a frame. > PyEval_GetLocals() now raises an exception and return NULL on failure. You'll have to either make this private or document it. ---------- assignee: docs@python components: Documentation messages: 201618 nosy: docs@python, georg.brandl, haypo, pitrou priority: normal severity: normal status: open title: Document PyFrame_FastToLocals() and PyFrame_FastToLocalsWithError() versions: Python 3.3, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue19431> _______________________________________

4 15

[issue33545] Docs for uuid don't mention that uuid1 can repeat in some circumstances
by merelymoray Sept. 20, 2018

Sept. 20, 2018

New submission from merelymoray <arcadesrofocale(a)yahoo.co.uk>: https://docs.python.org/3.6/library/uuid.html#uuid.UUID uuid.uuid1(node=None, clock_seq=None) Generate a UUID from a host ID, sequence number, and the current time. If node is not given, getnode() is used to obtain the hardware address. If clock_seq is given, it is used as the sequence number; otherwise a random 14-bit sequence number is chosen. ^^ This neglects to mention that if you call uuid1() in quick succession with no parameters, you can get a repeat uuid. I had a bug because of this. It would have been nice if the docs mentioned the fact directly. It's only a sentence to add, and would have saved a lot of time. ---------- assignee: docs@python components: Documentation messages: 316844 nosy: docs@python, merelymoray priority: normal severity: normal status: open title: Docs for uuid don't mention that uuid1 can repeat in some circumstances type: enhancement versions: Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue33545> _______________________________________

2 1

[issue21702] asyncio: remote_addr of create_datagram_endpoint() is not documented
by STINNER Victor Sept. 20, 2018

Sept. 20, 2018

New submission from STINNER Victor: See issue #21701 for a recent issue about this parameter. ---------- assignee: docs@python components: Documentation, asyncio messages: 220147 nosy: ariddell, docs@python, gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: asyncio: remote_addr of create_datagram_endpoint() is not documented versions: Python 3.4, Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue21702> _______________________________________

1 1

[issue33216] Wrong order of stack for CALL_FUNCTION_VAR and CALL_FUNCTION_VAR_KW
by Manuel Vazquez Acosta Sept. 17, 2018

Sept. 17, 2018

New submission from Manuel Vazquez Acosta <manuel(a)merchise.org>: The documentation of the dis module says that: CALL_FUNCTION_VAR (argc) Calls a function. *argc* is interpreted as in CALL_FUNCTION. The top elements on the stack are the keyword arguments, followed by the variable argument list, and then the positional arguments. However, inspecting the how ``f(b=1, *args)`` is actually compiled shows a different order: >>> import dis >>> dis.dis(compile('f(b=1, *args)', '<>', 'eval')) 1 0 LOAD_NAME 0 (f) 3 LOAD_NAME 1 (args) 6 LOAD_CONST 0 ('b') 9 LOAD_CONST 1 (1) 12 CALL_FUNCTION_VAR 256 (0 positional, 1 keyword pair) 15 RETURN_VALUE Notice that the top of the stack contains the explicit keyword arguments. The documentation of CALL_FUNCTION_VAR_KW is also incorrect. ---------- assignee: -> docs@python components: +Documentation nosy: +docs@python title: CALL_FUNCTION_VAR -> Wrong order of stack for CALL_FUNCTION_VAR and CALL_FUNCTION_VAR_KW versions: +Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue33216> _______________________________________

7 26

[issue25296] Simple End-of-life guide covering all unsupported versions
by Nick Coghlan Sept. 15, 2018

Sept. 15, 2018

New submission from Nick Coghlan: Katie McLaughlin recently pointed me at PHP's summary page for the End-of-Life dates for their various releases: http://php.net/eol.php That seems like a useful thing to offer, but we unfortunately don't currently have a great place for this kind of documentation: - the main docs are version specific, while this kind of page should be version independent - the update process, access control model and reader experience for python.org is too different from that for the main documentation - ditto for the wiki - informational PEPs are closer from an access control perspective, but aren't generated with Sphinx and are still disconnected from the main docs from a reader perspective - it's off-topic for the developer guide The "right" answer seems to be setting up a separate "docs" project on hg.python.org to use as the landing page for docs.python.org and for version independent information like this (the redirects already defined as part of PEP 430 should continue to handle unqualified deep links into the Python 2 docs). I'm not sure how much reconfiguration work such a change would entail, though. ---------- assignee: docs@python components: Documentation messages: 252084 nosy: docs@python, ncoghlan priority: normal severity: normal status: open title: Simple End-of-life guide covering all unsupported versions type: enhancement _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25296> _______________________________________

12 18

[issue28955] Not matched behavior of numeric comparison with the documentation
by woo yoo Sept. 14, 2018

Sept. 14, 2018

New submission from woo yoo: According to the documentation, which said "Additionally, comparing any number to a not-a-number value will return False. ",the comparison of `float('nan')!= 1`should yield False, while the result is True. Small errors like this in documentation should be corrected? The related link https://docs.python.org/3/reference/expressions.html#value-comparisons ---------- assignee: docs@python components: Documentation messages: 283069 nosy: docs@python, woo yoo priority: normal severity: normal status: open title: Not matched behavior of numeric comparison with the documentation type: behavior versions: Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue28955> _______________________________________

7 8