Mailman 3 October 2010 - docs

[issue9442] Update sys.version doc
by Éric Araujo 10 Feb '12

10 Feb '12

New submission from Éric Araujo <merwok(a)netwok.org>: Attaching a patch to edit mention of “build number” in library/sys. I also don’t understand “The first three characters are used to identify the version in the installation directories (where appropriate on each platform)”, maybe someone who does could enlighten me. If #5778 is rejected, the doc will need another update to mention that there may be a newline in sys.version. ---------- assignee: docs@python components: Documentation files: sys.version1.diff keywords: patch messages: 112189 nosy: docs@python, merwok priority: normal severity: normal stage: patch review status: open title: Update sys.version doc versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file18289/sys.version1.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9442> _______________________________________

4 9

[issue9021] no copy.copy problem description
by anatoly techtonik 09 Feb '12

09 Feb '12

New submission from anatoly techtonik <techtonik(a)gmail.com>: `copy` module covers very important aspect of Python programming. However its documentation doesn't provide any intro or overview of this problem starting right from details. When people meet `copy` construction in the code - the refer to module documentation and its doesn't completely answer two basic questions they have: 1. why copy module is needed (i.e. what's the problem with var assignment) 2. when and where it should be used ---------- assignee: docs@python components: Documentation messages: 108069 nosy: docs@python, techtonik priority: normal severity: normal status: open title: no copy.copy problem description versions: Python 2.7, Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9021> _______________________________________

5 10

[issue9637] docs do not say that urllib uses HTTP_PROXY
by Kirikaza 10 Jan '12

10 Jan '12

New submission from Kirikaza <kirikaza(a)rambler.ru>: In practice urllib reads HTTP_PROXY firstly and then if HTTP_PROXY is empty urllib reads http_proxy. Documentation (http://docs.python.org/library/urllib.html) says nothing about HTTP_PROXY. Maybe it affects all the versions of Python. ---------- assignee: docs@python components: Documentation messages: 114319 nosy: docs@python, kirikaza priority: normal severity: normal status: open title: docs do not say that urllib uses HTTP_PROXY versions: Python 2.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9637> _______________________________________

5 11

[issue9349] document argparse's help=SUPPRESS
by Steven Bethard 03 Jan '12

03 Jan '12

New submission from Steven Bethard <steven.bethard(a)gmail.com>: Argparse supports silencing help for certain options using SUPPRESS. >>> parser = argparse.ArgumentParser() >>> parser.add_argument('--foo', help=argparse.SUPPRESS) >>> parser.print_help() usage: [-h] optional arguments: -h, --help show this help message and exit This should be documented in the description of help= http://docs.python.org/library/argparse.html#help ---------- assignee: docs@python components: Documentation messages: 111320 nosy: bethard, docs@python priority: normal severity: normal status: open title: document argparse's help=SUPPRESS versions: Python 2.7, Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9349> _______________________________________

3 2

[issue8646] PyUnicode_EncodeDecimal is undocumented
by Daniel Stutzbach 22 Nov '11

22 Nov '11

New submission from Daniel Stutzbach <daniel(a)stutzbachenterprises.com>: PyUnicode_EncodeDecimal is undocumented (although it's referenced in passing in the documentation for PyLong_FromUnicode). There's a lengthy comment in unicodeobject.h describing PyUnicode_EncodeDecimal, which could be converted more or less directly into documentation. ---------- assignee: docs@python components: Documentation messages: 105205 nosy: docs@python, stutzbach priority: normal severity: normal stage: needs patch status: open title: PyUnicode_EncodeDecimal is undocumented versions: Python 2.7, Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue8646> _______________________________________

4 6

[issue9302] Distutils document problem?
by Ray.Allen 26 Aug '11

26 Aug '11

New submission from Ray.Allen <ysj.ray(a)gmail.com>: The distutils api document for class Extension: http://docs.python.org/dev/py3k/distutils/apiref.html#distutils.core.Extens… Among the argument, in fact, the type of the arguments "sources", "include_dirs", "library_dirs", "libraries", "runtime_library_dirs" must be list, but all of them are marked as "string". I think this is a problem. Here is a patch for this, against py3k. ---------- assignee: docs@python components: Documentation files: distutils_apiref.diff keywords: patch messages: 110724 nosy: docs@python, ysj.ray priority: normal severity: normal status: open title: Distutils document problem? versions: Python 3.2 Added file: http://bugs.python.org/file18061/distutils_apiref.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9302> _______________________________________

5 18

[issue8982] argparse docs cross reference Namespace as a class but the Namespace class is not documented
by R. David Murray 29 Jul '11

29 Jul '11

New submission from R. David Murray <rdmurray(a)bitdance.com>: I wanted to find out if Namespace supported lookup by subscripting (args['someopt']), but the docs are silent on what Namespace is. (The answer, by the way, appears to be "no"; there is a feature request for this in issue 8979). ---------- assignee: bethard components: Documentation messages: 107653 nosy: bethard, docs@python, r.david.murray priority: normal severity: normal stage: needs patch status: open title: argparse docs cross reference Namespace as a class but the Namespace class is not documented type: behavior versions: Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue8982> _______________________________________

4 9

[issue9312] Fix usage of :option: markup in stdlib ReST docs
by Eli Bendersky 09 Jun '11

09 Jun '11

New submission from Eli Bendersky <eliben(a)gmail.com>: Due to a discussion on python-dev (Subject: "Markup of command-line options in Python's .rst documentation"), Georg Brandl checked in revision r82961 with a clarification of :option: markup which should only be used for Python interpreter's own flags. However, several modules in stdlib use :option: for their own command-line options, which creates confusion (these options get linked by Sphinx to unrelated Python options). I'm attaching a patch that fixes this issue for these files. The affected files are: Doc/library/idle.rst Doc/library/timeit.rst Doc/library/test.rst Doc/library/doctest.rst Doc/library/unittest.rst Doc/library/pydoc.rst Doc/library/webbrowser.rst Doc/library/compileall.rst Note1: :option: was fixed to `` markup (code snippet) as per the recommendation in the updated documentation guide Note2: I didn't patch trace.rst because it's overgoing a major rehaul (http://bugs.python.org/issue9264) ---------- assignee: docs@python components: Documentation messages: 110862 nosy: docs@python, eli.bendersky priority: normal severity: normal status: open title: Fix usage of :option: markup in stdlib ReST docs type: behavior versions: Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9312> _______________________________________

6 26

[issue9738] Document the encoding of functions bytes arguments of the C API
by STINNER Victor 30 May '11

30 May '11

New submission from STINNER Victor <victor.stinner(a)haypocalc.com>: Many C functions have bytes argument (char* type) but the encoding is not documented. If would not be a problem if the encoding was always the same, but it is not. Examples: - format of PyUnicode_FromFormat() should be encoded as ISO-8859-1 - filename of PyParser_ASTFromString() should be encoded as utf-8 - filename of PyErr_SetFromErrnoWithFilename() should be encoded to the filesystem encoding (with strict error handler, and not surrogateescape) - 's' argument of PyParser_ASTFromString() should be encoded as utf-8 if PyPARSE_IGNORE_COOKIE flag is set, otherwise the parser checks for #coding:xxx cookie (if there is no cookie, utf-8 is used) Attached patch is a try to document most low level functions. I choosed to add the name of function arguments in the headers because I consider that a header can be used as a quick documentation. I only touched .c files to change argument names. It is hard to get the right encoding, so I cannot ensure that my patch is correct. My patch is just a draft. I don't know if "encoded to utf-8" is the right expression. Or should it be "decoded as utf-8"? ---------- assignee: docs@python components: Documentation, Interpreter Core, Unicode files: encodings.patch keywords: patch messages: 115339 nosy: docs@python, haypo priority: normal severity: normal status: open title: Document the encoding of functions bytes arguments of the C API versions: Python 3.2 Added file: http://bugs.python.org/file18705/encodings.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9738> _______________________________________

5 12

[issue9382] os.popen referenced but not documented in Python 3.x
by Chris Rebert 30 May '11

30 May '11

New submission from Chris Rebert <pybugs(a)rebertia.com>: http://docs.python.org/py3k/library/os.html currently mentions os.popen() in several places. The docs for os.popen() itself say: 'These functions are described in section "File Object Creation"' However, unlike the 2.x version of that section ( http://docs.python.org/library/os.html#file-object-creation ), the os.popen*() family is not documented there [or indeed anywhere] anymore ( http://docs.python.org/py3k/library/os.html#os-newstreams ); the entire section now only documents os.fdopen(). The 2.7 docs say that the os.popen*() family are deprecated, and indeed, of the family, only os.popen() seems to still exist in Python 3.x (at least based on my testing via ideone.com). Thus, from what I can see, one of the following is the case: (A) The entire os.popen*() family is supposed be gone in Python 3.x, so os.popen() should be removed entirely from both the code and the docs. (B) os.popen() is the sole legitimate survivor of its family, and should be properly documented again. (C) os.popen() was left in as a kludge, shouldn't be mentioned in the docs, and possibly should be renamed os._popen() to reflect its status. So, which one of these is it? ---------- assignee: docs@python components: Documentation messages: 111597 nosy: cvrebert, docs@python priority: normal severity: normal status: open title: os.popen referenced but not documented in Python 3.x versions: Python 3.1 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9382> _______________________________________

6 6