Mailman 3 February 2011 - docs

[issue11160] ZipFile.comment expects bytes
by Xuanji Li 25 Oct '12

25 Oct '12

New submission from Xuanji Li <xuanji(a)gmail.com>: The documentation for zipfile describes ZipFile.comment as "The comment text associated with the ZIP file." From reading this I expect that setting it to a string is ok; however ZipFile.comment must actually be set to bytes (or a bytes-like object, I am not very sure). This may also unexpectedly affect old code because I saw one patch on the bug tracker that was written just last year that set ZipFile.comment to a string. IMO there are 2 ways to fix: 1) Change docs to mention that ZipFile.comment only accepts bytes 2) Patch zipfile.py to accept string and try to convert, throwing an error if the conversion fails ---------- assignee: docs@python components: Documentation, Library (Lib) messages: 128217 nosy: docs@python, haypo, xuanji priority: normal severity: normal status: open title: ZipFile.comment expects bytes versions: Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue11160> _______________________________________

4 4

[issue10405] IDLE breakpoint facility undocumented
by Ned Deily 20 Oct '12

20 Oct '12

New submission from Ned Deily <nad(a)acm.org>: In neither the IDLE section of the Library Reference nor in IDLE's own help file is there any documentation on how to use its breakpoint capability. Since the menu options only appear if the user knows to Right-click (or Control-click on OS X - see issue10404), it would be easy for a user to never realize that the breakpoint capability exists. ---------- assignee: docs@python components: Documentation, IDLE messages: 121121 nosy: docs@python, kbk, ned.deily, taleinat, terry.reedy priority: normal severity: normal status: open title: IDLE breakpoint facility undocumented versions: Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10405> _______________________________________

5 9

[issue10665] Update and expand unicodedata module documentation
by Alexander Belopolsky 26 Sep '12

26 Sep '12

New submission from Alexander Belopolsky <belopolsky(a)users.sourceforge.net>: unicodedata module documentation has not been updated to reflect transition to 6.0. Attached patch fixes the version and unicode.org links and starts making the documentation rely less on the unicode.org pages for basic understanding of the provided functionality. I am posting work in progress to solicit feedback on how much of the Unicode Standard information we would want to present here. On of the goals of this patch is to provide a standard reference that can be used throughout the library manual for basic Unicode concepts without sending the reader over to unicode.org. ---------- assignee: docs@python components: Documentation files: unicodedata-doc.diff keywords: patch messages: 123700 nosy: belopolsky, docs@python priority: normal severity: normal status: open title: Update and expand unicodedata module documentation versions: Python 3.2 Added file: http://bugs.python.org/file19990/unicodedata-doc.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10665> _______________________________________

6 25

[issue10376] ZipFile unzip is unbuffered
by James Hutchison 23 Jun '12

23 Jun '12

New submission from James Hutchison <jamesghutchison(a)gmail.com>: The Unzip module is always unbuffered (tested v.3.1.2 Windows XP, 32-bit). This means that if one has to do many small reads it is a lot slower than reading a chunk of data to a buffer and then reading from that buffer. It seems logical that the unzip module should default to buffered reading and/or have a buffered argument. Likewise, the documentation should clarify that there is no buffering involved when doing a read, which runs contrary to the default behavior of a normal read. start Zipfile read done 27432 reads done took 0.859 seconds start buffered Zipfile read done 27432 reads done took 0.072 seconds start normal read (default buffer) done 27432 reads done took 0.139 seconds start buffered normal read done 27432 took 0.137 seconds ---------- assignee: docs@python components: Documentation, IO, Library (Lib) messages: 120871 nosy: Jimbofbx, docs@python priority: normal severity: normal status: open title: ZipFile unzip is unbuffered type: performance versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10376> _______________________________________

9 17

[issue8652] Minor improvements to the "Handling Exceptions" part of the tutorial
by Marien Zwart 07 Jun '12

07 Jun '12

New submission from Marien Zwart <m_zwart(a)123mail.org>: Based on questions asked on freenode's #python by people reading the tutorial I would like to suggest two improvements to http://docs.python.org/tutorial/errors.html#handling-exceptions : - Mention the older "except SomeException, e:" syntax too, not just "except SomeException as e:". I have had people ask me to help them upgrade to a newer python because they thought their version of python did not support catching exception instances (their distro python being 2.5). A big fat warning that they're reading the Python 2.6 tutorial (with links to older tutorials) may also work. - Mention "except IOError as e" before mentioning "except IOError as (errno, strerror):". The latter is an advanced and relatively unusual trick, combining regular exception catching and unpacking. Those two concepts need to be explained before the combination is. I have had people ask me how to do "except KeyError as (key, insert_something_here):" because they thought they *always* needed those parens there. (perhaps just not mentioning unpacking here at all, using "except IOError as e:" and then using e.errno would make more sense, especially since "except IOError as (errno, strerror):" is a SyntaxError in python 3 and up (because of the unpacking) and python 2.5.x and down (because of the "as")...) I can try to write a patch to the documentation if you like. ---------- assignee: docs@python components: Documentation messages: 105218 nosy: docs@python, marienz priority: normal severity: normal status: open title: Minor improvements to the "Handling Exceptions" part of the tutorial _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue8652> _______________________________________

4 6

[issue8617] Non-existent variables documented
by Dave Abrahams 09 May '12

09 May '12

New submission from Dave Abrahams <dave(a)boostpro.com>: http://docs.python.org/library/site.html#module-site mentions two variables that don't appear in my Python 2.6.5 installation's site module: PYTHONNOUSERSITE New in version 2.6. PYTHONUSERBASE New in version 2.6. ---------- assignee: docs@python components: Documentation messages: 104985 nosy: dabrahams, docs@python priority: normal severity: normal status: open title: Non-existent variables documented versions: Python 2.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue8617> _______________________________________

6 13

[issue10423] s/args/options in arpgarse "Upgrading optparse code"
by Steven Bethard 30 Mar '12

30 Mar '12

New submission from Steven Bethard <steven.bethard(a)gmail.com>: >From a personal email: ---------------------------------------------------------------------- I'm not signed up for all the Python issue tracking stuff, but thought I'd let you know about a problem with the argparse doc page: http://docs.python.org/library/argparse.html It says at the end: Replace options, args = parser.parse_args() with args = parser.parse_args() and add additional ArgumentParser.add_argument() calls for the positional arguments. But I think it should be options = parser.parse_args(), not args. ---------------------------------------------------------------------- They're not options, so I don't like encouraging people to continue to call them options, but the docs should at least make clear that the namespace object that used to be called "options" is now called "args". ---------- assignee: docs@python components: Documentation messages: 121219 nosy: bethard, docs@python priority: normal severity: normal stage: needs patch status: open title: s/args/options in arpgarse "Upgrading optparse code" versions: Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10423> _______________________________________

5 8

[issue11310] Document byte[s|array]() and byte[s|array](count) in docstrings
by Terry J. Reedy 30 Mar '12

30 Mar '12

New submission from Terry J. Reedy <tjreedy(a)udel.edu>: The entry for bytearray(source...) says " The optional source parameter can be used to initialize the array in a few different ways: ... If it is an integer, the array will have that size and will be initialized with null bytes. ... Without an argument, an array of size 0 is created. " [integer must be non-negative -- patch adds this] The entry for bytes(source...) refers back to the bytearray entry. The docstrings for bytes and bytearray omit both possibilities. Attached is a possible patch to include them. ---------- assignee: docs@python components: Documentation files: zbytes.diff keywords: patch messages: 129299 nosy: docs@python, terry.reedy priority: normal severity: normal status: open title: Document byte[s|array]() and byte[s|array](count) in docstrings versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file20877/zbytes.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue11310> _______________________________________

3 2

[issue10713] re module doesn't describe string boundaries for \b
by Ralph Corderoy 29 Feb '12

29 Feb '12

New submission from Ralph Corderoy <ralph-pythonbugs(a)inputplus.co.uk>: The re module defines \b in a regexp to need \w one side and \W the other. What about when the end of the string or line is involved? perlre(1) says that's treated as a \W. Python should precisely document that case too. ---------- assignee: docs@python components: Documentation messages: 124097 nosy: docs@python, ralph.corderoy priority: normal severity: normal status: open title: re module doesn't describe string boundaries for \b _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10713> _______________________________________

6 9

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

09 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