Mailman 3 February 2014 - docs

[issue12743] C API marshalling doc contains XXX
by JJeffries July 27, 2018

July 27, 2018

New submission from JJeffries <jamesjeffries1(a)gmail.com>: The Python C API manual page for data marshaling contains the following paragraph. XXX What about error detection? It appears that reading past the end of the file will always result in a negative numeric value (where that’s relevant), but it’s not clear that negative values won’t be handled properly when there’s no error. What’s the right way to tell? Should only non-negative values be written using these routines? I suggest that the XXX should be removed as it is unclear why it's there. Patch to follow in the next couple of days if others agree. ---------- assignee: docs@python components: Documentation messages: 141959 nosy: JJeffries, docs@python priority: normal severity: normal status: open title: C API marshalling doc contains XXX _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12743> _______________________________________

7 13

[issue17286] Make subprocess handling text output with universal_newlines more obious
by Baptiste Lepilleur June 11, 2018

June 11, 2018

New submission from Baptiste Lepilleur: It tooks me a while to figure out that using universal_newlines was the solution to "tell" subprocess that I wanted text string output instead of byte string. A search on stackoverflow shows that this issue is common and the solution nearly unknown (answer is usually to decode the byte string manually)... Because dealing with text output is IMHO the most common use case, the subprocess documentation should make it easier to "find" the recipe. I would suggest changing the documentation so that the universal_newlines is made obvious as it is very important: 1) the first /bin/vikings example be modified to show the use of this flag (at the top of the documentation, most people copy/past that): >>> p = subprocess.Popen(args, universal_newlines=True) # Success! and at a small comment below the example to explain that flag 2) change other example similarly when that make sense, IMHO: - ifconfig example - one of the subprocess.check_output example - subprocess.check_output() example, consider separating the byte string / text string example for increased visibility 3) consider adding a section with an obvious title "Dealing with binary and text input/output", providing examples and pointer to the correct documentation (I would place it after the convenience functions section for visibility). I think this would help attracting "eye" on this large piece of documentation. ---------- assignee: docs@python components: Documentation messages: 182872 nosy: Baptiste.Lepilleur, docs@python priority: normal severity: normal status: open title: Make subprocess handling text output with universal_newlines more obious type: enhancement versions: Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17286> _______________________________________

5 5

[issue19950] Document that unittest.TestCase.__init__ is called once per test
by Claudiu.Popa May 19, 2018

May 19, 2018

New submission from Claudiu.Popa: I was surprised that in the following __init__ is actually called once per test function, although nothing in documentation implied so. a.py ------ import unittest class A(unittest.TestCase): def __init__(self, *args, **kwargs): print('called only once!') super().__init__(*args, **kwargs) def test(self): self.assertEqual(1, 1) def test2(self): self.assertEqual(2, 2) if __name__ == '__main__': unittest.main() $ python a.py called only once! called only once! .. ---------------------------------------------------------------------- Ran 2 tests in 0.001s OK The attached patch adds a note regarding this behaviour for the TestCase class. ---------- assignee: docs@python components: Documentation files: unittest_init.patch keywords: patch messages: 205864 nosy: Claudiu.Popa, docs@python, michael.foord priority: normal severity: normal status: open title: Document that unittest.TestCase.__init__ is called once per test type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file33086/unittest_init.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue19950> _______________________________________

8 15

[issue13525] Tutorial: Example of Source Code Encoding triggers error
by Nicolas Goutte May 9, 2018

May 9, 2018

New submission from Nicolas Goutte <nicolas.goutte(a)extragroup.de>: Current Behaviour The tutorial of Python 3.2.x has an example to set an encoding in a source file: http://docs.python.org/py3k/tutorial/interpreter.html#source-code-encoding It explains to set the following line at the start of the source code: # -*- coding: cp-1252 -*- However when done exactly so, Python raises the following exception: SyntaxError: encoding problem: with BOM The problem seems to be that Python knows Windows codepage 1252 as windows-1252 (its IANA charset name, see http://www.iana.org/assignments/charset-reg/windows-1252 ) or alternatively as cp1252 (without dash) but not as cp-1252 (with dash). As this is an example in the tutorial is particularly problematic, as users might not understand how to do it correctly. This is still the case in the tutorial of Python 3.3 alpha: http://docs.python.org/dev/tutorial/interpreter.html#source-code-encoding Expected Behaviour The tutorial should give a correct example, for example with: # -*- coding: windows-1252 -*- Alternatively a totally other example as for Python 2.7 would be nice too: http://docs.python.org/tutorial/interpreter.html#source-code-encoding Notes: I have tested this with following Python implementations: - Python 3.2.1 (openSUSE 12.1) on Linux - Python 3.2.2 on Windows 7 SP1 64 Bits - Python 3.2.2 on MacOS 10.5.8 (Always on the command line; I have not tested in IDLE.) ---------- assignee: docs@python components: Documentation files: cp_1252broken.py messages: 148798 nosy: docs@python, nicolasg priority: normal severity: normal status: open title: Tutorial: Example of Source Code Encoding triggers error versions: Python 3.2 Added file: http://bugs.python.org/file23840/cp_1252broken.py _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13525> _______________________________________

5 14

[issue20722] newline is (partially) independent of universal newlines; needs to be made more clear in docs
by Devin Jeanpierre May 3, 2018

May 3, 2018

New submission from Devin Jeanpierre: http://docs.python.org/3.4/library/functions.html#open says "newline controls how universal newlines mode works (it only applies to text mode)." My reading of this when I saw it was that newline= doesn't do anything unless universal newlines mode is enabled. This is untrue, and you can infer it's untrue from the following lines, but then the docs appear to contradict themselves. Please fix to say something more along the lines of "newline controls how newlines are read and written. It only applies to text mode." The interactions with universal newlines mode are explained in the following text, so they don't need to be called out upfront. newline does more than just that. ---------- assignee: docs@python components: Documentation messages: 211854 nosy: Devin Jeanpierre, docs@python priority: normal severity: normal status: open title: newline is (partially) independent of universal newlines; needs to be made more clear in docs versions: Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue20722> _______________________________________

3 2

[issue13677] correct docstring for builtin compile
by Jim Jewett March 22, 2018

March 22, 2018

New submission from Jim Jewett <jimjjewett(a)gmail.com>: The current docstring for compile suggests that the flags are strictly for selecting future statements. These are not the only flags. It also suggests that the source must be source code and the result will be bytecode, which isn't quite true. I suggest changing: "The flags argument, if present, controls which future statements influence the compilation of the code." to: "The flags argument, if present, largely controls which future statements influence the compilation of the code. (Additional flags are documented in the AST module.)" ---------- assignee: docs@python components: Documentation files: bltinmodule.c.patch keywords: patch messages: 150337 nosy: Jim.Jewett, docs@python priority: normal severity: normal status: open title: correct docstring for builtin compile type: behavior Added file: http://bugs.python.org/file24105/bltinmodule.c.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13677> _______________________________________

4 6

[issue18855] Inconsistent README filenames
by Madison May March 1, 2018

March 1, 2018

New submission from Madison May: Is there any reason (other than backwards compatibility) that the names of README files are inconsistent? README: 3 instances - root, /Mac, /Misc, /Tools readme.txt: 2 instances - /PC, /PCbuild README.txt: 1 instance - /Doc ---------- assignee: docs@python components: Documentation messages: 196299 nosy: docs@python, madison.may priority: normal severity: normal status: open title: Inconsistent README filenames _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue18855> _______________________________________

11 11

[issue19894] zipfile ignores deflate level settings in zipinfo object
by Richard Milne Feb. 25, 2018

Feb. 25, 2018

New submission from Richard Milne: Reading the pkzip APPNOTE and the documentation for the zipfile module, I was under the impression that I could set the DEFLATE compression level, on a per-file basis, for each file added to an archive, by setting the appropriate bits in zipinfo.flag_bits. You can't. Hence the attached patch, which updates the docs, tests and module source to enables this ability and makes the user aware of it. ---------- assignee: docs@python components: Documentation, Library (Lib), Tests files: zipfileinfo.diff keywords: patch messages: 205284 nosy: docs@python, rmilne priority: normal severity: normal status: open title: zipfile ignores deflate level settings in zipinfo object type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file32984/zipfileinfo.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue19894> _______________________________________

4 4

[issue17232] Improve -O docs
by Maciej Fijalkowski Feb. 25, 2018

Feb. 25, 2018

New submission from Maciej Fijalkowski: This is what the current documentation says: -O Turn on basic optimizations. This changes the filename extension for compiled (bytecode) files from .pyc to .pyo. See also PYTHONOPTIMIZE. -OO Discard docstrings in addition to the -O optimizations. As far as I know, the only "optimization" that's done is removal of __debug__ sections and assert statements and has been like this for years. Maybe it should say so "-O does not do any optimizations, only removes assert statement" or so. ---------- assignee: docs@python components: Documentation messages: 182365 nosy: docs@python, fijall priority: normal severity: normal status: open title: Improve -O docs type: behavior _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17232> _______________________________________

15 33

[issue18356] help(numpy) causes segfault on exit
by Michelle Arzul Feb. 22, 2018

Feb. 22, 2018

New submission from Michelle Arzul: As far as we could tell this bug is only consistently reproducible on Ubuntu 13.04. A line in pydoc.py causes a segfault when help(numpy) (no other libraries that I know of) exits. The offending method is pipepager(). For a full trackdown and workaround of the problem see http://stackoverflow.com/questions/17344974/python-helpnumpy-causes-segfaul… ---------- assignee: docs@python components: Documentation messages: 192276 nosy: Leeward, docs@python priority: normal severity: normal status: open title: help(numpy) causes segfault on exit type: crash versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue18356> _______________________________________

6 9