Mailman 3 December 2012 - docs

[issue15258] argparse documentation: Improve optparse section regarding allow_interspersed_args
by Nefarious CodeMonkey, Jr. Aug. 14, 2018

Aug. 14, 2018

New submission from Nefarious CodeMonkey, Jr. <nejucomo(a)users.sourceforge.net>: It was not obvious from the documentation on argparse how to emulate the optparse.OptionParser.allow_interspersed_args feature. Please add something like the following to the section titled "Upgrading optparse code" (see: http://docs.python.org/library/argparse.html#upgrading-optparse-code ) """ * If the optparse code sets allow_interspersed_args to False, then add an argparse positional argument with nargs=argparse.REMAINDER """ ---------- assignee: docs@python components: Documentation messages: 164702 nosy: docs@python, nejucomo priority: normal severity: normal status: open title: argparse documentation: Improve optparse section regarding allow_interspersed_args type: enhancement versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15258> _______________________________________

5 4

[issue13574] refresh example in doc for Extending and Embedding
by Florent Xicluna Aug. 4, 2018

Aug. 4, 2018

New submission from Florent Xicluna <florent.xicluna(a)gmail.com>: The example uses PyInstanceObject which is Python 2 only (old-style classes). http://docs.python.org/dev/extending/newtypes.html#weak-reference-support ---------- assignee: docs@python components: Documentation, Extension Modules messages: 149183 nosy: docs@python, flox priority: normal severity: normal stage: needs patch status: open title: refresh example in doc for Extending and Embedding type: behavior versions: Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13574> _______________________________________

6 5

[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

[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

[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

[issue11015] Bring test.support docs up to date
by Nick Coghlan Feb. 11, 2018

Feb. 11, 2018

New submission from Nick Coghlan <ncoghlan(a)gmail.com>: The test.support docs are there to help CPython devs with writing good unit tests more easily. There are a few additions we've made in recent years that haven't made it into the .rst file, so it is easy to miss useful tools if you don't go looking through the module source code. There are some other helper modules (such as test.script_helper) that could also stand to be made easier to find. Fixing this is just a matter of doing a pass through test.support and the test directory looking for things that might be worth mentioning in the test package docs. ---------- assignee: docs@python keywords: easy messages: 127086 nosy: docs@python, ncoghlan priority: normal severity: normal stage: needs patch status: open title: Bring test.support docs up to date type: behavior _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue11015> _______________________________________

11 36

[issue8722] Documentation for __getattr__
by Paul Davis Feb. 5, 2018

Feb. 5, 2018

New submission from Paul Davis <paul.joseph.davis(a)gmail.com>: The docs for __getattr__ in the object model section could be more specific on the behavior when a @property raises an AttributeError and there is a custom __getattr__ defined. Specifically, it wasn't exactly clear that __getattr__ would be invoked after a @property was found and evaluated. The attached script demonstrates the issue on OS X 10.6, Python 2.6.1 I'm thinking something along the lines of: If the attribute search encounters an AttributeError (perhaps due to a @property raising the error) the search is considered a failure and __getattr__ is invoked. ---------- assignee: docs@python components: Documentation files: example.py messages: 105790 nosy: Paul.Davis, docs@python priority: normal severity: normal status: open title: Documentation for __getattr__ type: feature request versions: Python 2.6 Added file: http://bugs.python.org/file17349/example.py _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue8722> _______________________________________

8 23

[issue11023] pep 227 missing text
by Alan Isaac Jan. 26, 2018

Jan. 26, 2018

New submission from Alan Isaac <alan.isaac(a)gmail.com>: In PEP 227 missing text is marked with XXX. Most of this is just calls for examples and elaboration. However under the Implementation section XXX marks a substantive question about the documentation. Fixing this may be low priority, but a tracker search suggested it is currently not even being tracked ... ---------- assignee: docs@python components: Documentation messages: 127184 nosy: aisaac, docs@python priority: normal severity: normal status: open title: pep 227 missing text type: feature request _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue11023> _______________________________________

4 3

[issue12706] timeout sentinel in ftplib and poplib
by Senthil Kumaran Jan. 25, 2018

Jan. 25, 2018

New submission from Senthil Kumaran <senthil(a)uthcode.com>: - ftplib and poplib, has them as timeout=None, while they default to socket._GLOBAL_DEFAULT_TIMEOUT object. This is wrong; someone may pass None thinking it will trigger the default behaviour, and have nasty surprises. ---------- assignee: docs@python messages: 141740 nosy: docs@python, orsenthil priority: normal severity: normal stage: needs patch status: open title: timeout sentinel in ftplib and poplib type: behavior versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12706> _______________________________________

5 7

[issue15221] os.path.is*() may return False if path can't be accessed
by Giampaolo Rodola' Jan. 15, 2018

Jan. 15, 2018

New submission from Giampaolo Rodola' <g.rodola(a)gmail.com>: It seems a doc fix is the best way to go, in which case I leave this one to a native English speaker: http://mail.python.org/pipermail/python-dev/2012-June/120788.html Alternatively a new 'strict' parameter has been proposed as a workaround: http://mail.python.org/pipermail/python-dev/2012-June/120800.html ---------- assignee: docs@python components: Documentation messages: 164307 nosy: christian.heimes, docs@python, eric.araujo, ezio.melotti, georg.brandl, giampaolo.rodola, ncoghlan priority: normal severity: normal status: open title: os.path.is*() may return False if path can't be accessed versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15221> _______________________________________

7 9