Mailman 3 December 2017 - docs

[issue32145] Wrong ExitStack Callback recipe
by Maurizio Zucchelli 02 Jan '18

02 Jan '18

New submission from Maurizio Zucchelli <mauzuc90(a)yahoo.it>: The documentation for contextlib.ExitStack (https://docs.python.org/3.7/library/contextlib.html#replacing-any-use-of-tr…) shows an helper class (Callback) to perform cleanup using a callback. Problem is, Callback.cancel() calls ExitStack.pop_all(), which in turn calls type(self)(), this is not a valid constructor for Callback, since it always expects at least one element. (I have marked only Python 3.4 and 3.6 since those are the versions where I verified this, but it likely applies to every version.) ---------- assignee: docs@python components: Documentation messages: 307037 nosy: Denaun, docs@python priority: normal severity: normal status: open title: Wrong ExitStack Callback recipe type: crash versions: Python 3.4, Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue32145> _______________________________________

4 8

ElementTree documentation error
by Todd Wells 31 Dec '17

31 Dec '17

I found this error in the documentation (https://docs.python.org/3.7/library/xml.etree.elementtree.html <https://docs.python.org/3.7/library/xml.etree.elementtree.html> and earlier versions): xml.etree.ElementTree.tostring(element, encoding="us-ascii", method="xml", *, short_empty_elements=True) <https://docs.python.org/3.7/library/xml.etree.elementtree.html#xml.etree.El…> Generates a string representation of an XML element, including all subelements. element is an Element <https://docs.python.org/3.7/library/xml.etree.elementtree.html#xml.etree.El…> instance. encoding [1] <https://docs.python.org/3.7/library/xml.etree.elementtree.html#id5> is the output encoding (default is US-ASCII). Use encoding="unicode" to generate a Unicode string (otherwise, a bytestring is generated). method is either "xml", "html" or "text" (default is "xml"). short_empty_elements has the same meaning as in ElementTree.write() <https://docs.python.org/3.7/library/xml.etree.elementtree.html#xml.etree.El…>. Returns an (optionally) encoded string containing the XML data. The error here is the method value “text” is not a valid argument as the docs state. The correct value is “us-ascii”. From an error I encountered: Traceback (most recent call last): File "/Users/todd.wells/Dropbox/thePlatform SA/aws/lambda-ingest-proxy/modify-title-handler/test_modify_title_handler.py", line 11, in test_modify_title modified = handler.lambda_handler(event, None) File "/Users/todd.wells/Dropbox/thePlatform SA/aws/lambda-ingest-proxy/modify-title-handler/modify_title_handler.py", line 17, in lambda_handler event['body'] = ET.tostring(root, encoding='text', method='xml') File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/xml/etree/ElementTree.py", line 1135, in tostring short_empty_elements=short_empty_elements) File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/xml/etree/ElementTree.py", line 759, in write with _get_writer(file_or_filename, enc_lower) as write: File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/contextlib.py", line 82, in __enter__ return next(self.gen) File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/xml/etree/ElementTree.py", line 831, in _get_writer newline="\n") LookupError: unknown encoding: text Using “us-ascii” instead of “text” works.

1 1

output not correctly shown
by P R Siyag 30 Dec '17

30 Dec '17

On this page: 4. More Control Flow Tools — Python 3.6.4 documentation | | | | 4. More Control Flow Tools — Python 3.6.4 documentation | | | the output starts with '3 is a prime number' and not ' '2 is a prime number' when I run it :4.4. break and continue Statements, and else Clauses on Loops

1 0

[issue32444] python -m venv symlink dependency on how python binary is called is not documented
by R. David Murray 29 Dec '17

29 Dec '17

R. David Murray <rdmurray(a)bitdance.com> added the comment: Actually, I'm going to reopen this as a doc issue because this behavior is not discussed by the docs that I can see, and it is important to know about when creating a venv. ---------- assignee: -> docs@python components: +Documentation -Library (Lib) nosy: +docs@python resolution: not a bug -> stage: resolved -> needs patch status: closed -> open title: python -m venv has incongruous behavor creating binaries -> python -m venv symlink dependency on how python binary is called is not documented _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue32444> _______________________________________

1 0

[issue32440] Use HTTPS in help()
by Old K 28 Dec '17

28 Dec '17

New submission from Old K <oldk1331(a)gmail.com>: In python3, in the output of help(), there is link http://docs.python.org/3.6/tutorial/. It should be made into https. There are already some issues about changing http links to https: https://bugs.python.org/issue25910 https://bugs.python.org/issue26736 But this link is still unchanged. ---------- assignee: docs@python components: Documentation messages: 309127 nosy: Old K, docs@python priority: normal severity: normal status: open title: Use HTTPS in help() versions: Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue32440> _______________________________________

3 6

2.7.14 English text-only Documentation archive contains Japanese UTF-8
by Oisin Feeley 28 Dec '17

28 Dec '17

Hello, I just (27 DEC 2017) downloaded the English 2.7.14 archive[1] of the documentation and find that at least the "csv" module information in the standard library contains interspersed blocks of (apparently) Japanese and English characters, with significant blocks of the requisite English text being entirely replaced. I am viewing the docs with "less" and "vim" in a BASH shell on GNU/Linux. The possibly apposite environment variables are set as follows: BASH shell: [ush@swift Downloads]$ env | egrep -i '(locale|lang|lc)' LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8 GDM_LANG=en_US.UTF-8 LANGUAGE=en_US.UTF-8 vim: Current language: "LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=en_US.UTF-8;LC_ME SSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=en_US.UTF-8;LC_ADDRESS=en_US.UTF-8;LC_TELEPHONE=en_US.UTF-8;LC_MEASUREMENT=en _US.UTF-8;LC_IDENTIFICATION=en_US.UTF-8" So, is the problem on my end, or is your build-chain linking to the wrong docs on the web page? Thank you, Oisin 1. https://docs.python.org/2/archives/python-2.7.14-docs-text.tar.bz2 (Selected 2.7.14 > English from the dropdowns)

1 0

[issue32374] Document that m_traverse for multi-phase initialized modules can be called with m_state=NULL
by Nick Coghlan 26 Dec '17

26 Dec '17

Nick Coghlan <ncoghlan(a)gmail.com> added the comment: Yep, the requirement for supporting multiple interpreters is just that you either avoid relying on C global state entirely, or else correctly synchronise access to it. Multi-phase initialisation just provides a few nudges in the direction of doing that more consistently. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue32374> _______________________________________

1 0

7.2 Reading and Writing Files - No empty secondary prompt after "with" block
by Adrián Herrera Arcila 26 Dec '17

26 Dec '17

Only happening in docs for Python 3. The statement: >>> with open('workfile') as f: . . . read_data = f.read() >>> f.closed True should be: >>> with open('workfile') as f: . . . read_data = f.read() . . . >>> f.closed True This would avoid people writing the code by themselves (instead of copying and pasting it) making the mistake of introducing "f.closed" in the secondary prompt after the end of the "with" compound. Thanks in advance and have a beautiful day, Adrián.

1 0

[issue31983] Officially add Py_SETREF and Py_XSETREF
by Serhiy Storchaka 25 Dec '17

25 Dec '17

New submission from Serhiy Storchaka <storchaka+cpython(a)gmail.com>: Private macros Py_SETREF and Py_XSETREF were introduced in 3.6 and backported to all maintained versions for fixing bugs (see issue20440 and issue26200). They are helpful and used not only for the primary purpose, but also for simplifying the code. Their names don't start from underscore because I planned to make them public and didn't want massive renaming and backporting conflicts. Now I think it is a time to add them officially to the stable C API. ---------- assignee: docs@python components: Documentation, Interpreter Core messages: 305878 nosy: docs@python, serhiy.storchaka priority: normal severity: normal status: open title: Officially add Py_SETREF and Py_XSETREF type: enhancement versions: Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue31983> _______________________________________

4 6

English text doc downloads for 2.7.14 are in Japanese
by James Kneuper 25 Dec '17

25 Dec '17

Greetings, I just downloaded the Python documentation from: https://docs.python.org/2.7/archives/python-2.7.14-docs-text.zip Which is linked from this page: https://docs.python.org/2.7/download.html And the resulting documents were in Japanese. Same with the bzip2 version. Thinking there may have been a swap, I tried switching to the Japanese docs page and hit their download link, but that produced a 404. The HTML version seems fine so I may just feed those through beautiful soup for now. Thought you might want to know :) Cheers, -Jim

1 0