Mailman 3 September 2012 - docs

[issue13030] Be more generic when identifying the Windows main dir in installation doc
by Sandro Tosi 06 May '14

06 May '14

New submission from Sandro Tosi <sandro.tosi(a)gmail.com>: Given I have no knowledge of the windows system, I'm just proxying http://mail.python.org/pipermail/docs/2011-September/005793.html : >>> Under: http://docs.python.org/install/index.html#inst-how-install-works It notes "Windows prefix\Lib\site-packages C:\PythonXY\Lib\site-packages" for default values on Windows. In the paragraph following the table is the text: "prefix and exec-prefix stand for the directories that Python is installed to, and where it finds its libraries at run-time. They are always the same under Windows, and very often the same under Unix and Mac OS X. " I don't know if it's hardcoded into Python distributions to use C, but it's not correct. The correct way to identify what most people think of as C is via the %SYSTEMROOT% environment variable, so the path described would be "%SYSTEMROOT%\PythonXY\Lib\site-packages" (This is still not the correct way to do things on Windows, but it at least shouldn't break on systems with a %SYSTEMROOT% other than C. I've seen configurations like that on systems which boot multiple versions of Windows.) <<< ---------- assignee: docs@python components: Documentation messages: 144422 nosy: brian.curtin, docs@python, sandro.tosi, tim.golden priority: normal severity: normal stage: needs patch status: open title: Be more generic when identifying the Windows main dir in installation doc type: behavior versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13030> _______________________________________

4 5

[issue9307] Py_TPFLAGS_LONG_SUBCLASS is not documented
by Alexander Belopolsky 28 Apr '14

28 Apr '14

New submission from Alexander Belopolsky <belopolsky(a)users.sourceforge.net>: Is there a reason for not documenting Py_TPFLAGS_LONG_SUBCLASS (Py_TPFLAGS_INT_SUBCLASS in 2.x)? This flag is used in PyLong_Check, but neither this flag or its inheritance properties are explained anywhere in the docs. See also issue5476. ---------- assignee: docs@python components: Documentation messages: 110787 nosy: belopolsky, docs@python priority: normal severity: normal stage: needs patch status: open title: Py_TPFLAGS_LONG_SUBCLASS is not documented type: feature request _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9307> _______________________________________

6 8

[issue9364] some problems with the documentation of pydoc
by Eli Bendersky 19 Apr '14

19 Apr '14

New submission from Eli Bendersky <eliben(a)gmail.com>: The first paragraph in its documentation says: """ In the Python interpreter, do "from pydoc import help" to provide online help. Calling help(thing) on a Python object documents the object. """ Which is no longer accurate, because the help() function has long ago become a built-in. Below is an excerpt from Terry Reedy in a private email discussion on this subject, that raises more issues. --------------------------------------------- 1. The output from help(help) could be made more clear. The nature of 'help' has been a point of confusion. A recent python-list post asked something like "What is 'help'?" Now (with some parallel examples: >>> help(int) Help on class int in module builtins: class int(object) [snip] >>> help(1) Help on int object: class int(object) [snip] >>> help(help) Help on _Helper in module site object: class _Helper(builtins.object) | Define the built-in 'help'. | This is a wrapper around pydoc.help (with a twist). | | Methods defined here: | | __call__(self, *args, **kwds) | a. 'module site object' is nonsense, it should just be 'module site', except that to be parallel to what is done for other instances, it should be 'Help on _Helper object'. Why should help special-case itself (with a slightly garbled line?) Is that done in site._Helper or pydoc.help? However, it would be more helpful for all instances to give the location of the class when one asks for help on an instance, just as when one asks for help on the class itself. It is annoying to to have to repeat help(<classname>) just to get that info. So I would like to see "Help on instance of class int in module builtins:" "Help on instance of class _Helper in module site:" This would be a code patch to pydoc.help b. "This is a wrapper around pydoc.help" good so far "(with a twist)" thanks a lot. I think the comment should be either removed or explained. A reference manual should explain, not tease. Replace "Define the built-in 'help'." with something clearer and more accurate, such as "The name 'help' is injected in module builtins after being bound to an instance of this class.". Put this after, not before, the 'wrapper' line. A patch for site._Helper doc string. 2. Improve manual chapter for site module. a. It currently starts "Importing this module will append site-specific paths to the module search path." Add "inject 'help' into builtins and " after append. Then add a short explanation paragraph before the search path stuff. Something like "This module contains a class (_Helper) that wraps function pydoc.help. An instance of the class is bound to name 'help' in the builtins module." A recent discussion on pydev or maybe python-list (in the thread mentioned above?) implied that one could usefully make another instance of _Helper or maybe a subclass thereof. I did not pay enough attention, though, to really get it. b. It currently ends with "XXX Update documentation XXX document python -m site –user-base –user-site" ---------- assignee: docs@python components: Documentation messages: 111426 nosy: docs@python, eli.bendersky, tjreedy priority: normal severity: normal status: open title: some problems with the documentation of pydoc type: behavior versions: Python 3.1, Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9364> _______________________________________

9 21

[issue15840] Ambiguity with regard to the effect of accessing a closed IOBase instance
by Alexander Konovalenko 16 Apr '14

16 Apr '14

New submission from Alexander Konovalenko: Two pieces of the documentation for io.IOBase seem to contradict each other: At http://docs.python.org/library/io.html#io.IOBase: "Note that calling any method (even inquiries) on a closed stream is undefined. Implementations may raise IOError in this case." At http://docs.python.org/library/io.html#io.IOBase.close: "Once the file is closed, any operation on the file (e.g. reading or writing) will raise a ValueError." Perhaps the confusion arises in part because it is not clear when a requirement for all IOBase implementations is documented and when the docs merely describe the default behavior of IOBase that implementations are free to override. Those passages are inconsistent on two points: 1) IOError and ValueError are not subclasses one of another. So what should we expect an IOBase implementation to raise? 2) Undefined behavior means literally anything can happen. Technically, that means calling read() or readable() on a closed file (or other kind of stream) could wreak havoc in a totally unrelated part of the system or segfault the Python interpreter. That is definitely a thing to carefully avoid in any production systems. On the other hand, raising an exception, even if we don't know in advance whether it will be ValueError or IOError, is pretty much defined behavior. An exception is easy to deal with and to contain inside a module. So please clarify how dangerous it actually is to access an IOBase stream after it has been closed. ---------- assignee: docs@python components: Documentation messages: 169660 nosy: alexkon, docs@python priority: normal severity: normal status: open title: Ambiguity with regard to the effect of accessing a closed IOBase instance versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15840> _______________________________________

8 12

[issue10481] subprocess PIPEs are byte streams
by Glenn Linderman 14 Apr '14

14 Apr '14

New submission from Glenn Linderman <v+python(a)g.nevcal.com>: While http://bugs.python.org/issue2683 did clarify the fact that the .communicate API takes a byte stream as input, it is easy to miss the implication. Because Python programs start up with stdin as a text stream, it might be good to point out that some action may need to be taken to be sure that the receiving program expects a byte stream, or that the byte stream supplied should be in an encoding that the receiving program is expecting and can decode appropriately. No mention is presently made in the documentation for .communicate that its output is also a byte stream, and if text will correspond to whatever encoding is used by the sending program. ---------- assignee: docs@python components: Documentation messages: 121869 nosy: docs@python, v+python priority: normal severity: normal status: open title: subprocess PIPEs are byte streams versions: Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10481> _______________________________________

4 5

[issue15067] sqlite3 docs reference PEP 246, which was rejected
by Zachary Ware 01 Apr '14

01 Apr '14

New submission from Zachary Ware <zachary.ware(a)gmail.com>: See: http://hg.python.org/cpython/file/d31e83497c5a/Doc/library/sqlite3.rst#l708 PEP 246 is headed by: """ Rejection Notice I'm rejecting this PEP. Something much better is about to happen; it's too early to say exactly what, but it's not going to resemble the proposal in this PEP too closely so it's better to start a new PEP. GvR. """ I don't know what the "something much better" was/is, so I have no idea how that line in the docs should be replaced, but I don't think the PEP 246 reference is valid. Thanks, Zach ---------- assignee: docs@python components: Documentation messages: 162797 nosy: docs@python, ghaering, zach.ware priority: normal severity: normal status: open title: sqlite3 docs reference PEP 246, which was rejected versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15067> _______________________________________

4 12

[issue12209] Minor edits to faulthandler doc
by Éric Araujo 25 Mar '14

25 Mar '14

New submission from Éric Araujo <merwok(a)netwok.org>: I made some grammar fixes in faulthandler.rst and tweaked the example to better show what the module does. I’d like to fix the synopsis too: “dump the Python traceback” is not very clear to me. It is the traceback or the stack trace? Why is it called “the” traceback? Something like “dumping the stack trace on CPython crashes” would be better IMO. ---------- assignee: docs@python components: Documentation files: faulthandler-doc.diff keywords: needs review, patch messages: 137206 nosy: docs@python, eric.araujo, haypo priority: normal severity: normal stage: patch review status: open title: Minor edits to faulthandler doc versions: Python 3.3 Added file: http://bugs.python.org/file22177/faulthandler-doc.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12209> _______________________________________

3 7

[issue11481] The copy module already uses copyreg
by Daniel Urban 24 Mar '14

24 Mar '14

New submission from Daniel Urban <urban.dani+py(a)gmail.com>: In the copyreg documentation there is this sentence: "The copy module is likely to use this in the future as well." (http://docs.python.org/dev/py3k/library/copyreg) But the copy module already uses the copyreg module. ---------- assignee: docs@python components: Documentation messages: 130732 nosy: docs@python, durban priority: normal severity: normal status: open title: The copy module already uses copyreg versions: Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue11481> _______________________________________

5 5

[issue13437] Provide links to the source code for every module in the documentation
by Julian Berman 19 Mar '14

19 Mar '14

New submission from Julian Berman <Julian+Python.org(a)GrayVines.com>: The documentation occasionally contains a link to the source code for a module in the stdlib. See for instance http://docs.python.org/library/urlparse.html and http://docs.python.org/library/collections.html , or many others. With a quick perusal, I couldn't immediately guess as to which ones managed to have one and which ones don't, but it'd be convenient to have a link in as many places as possible, which is certainly more than we have now. (See e.g. http://docs.python.org/library/json.html and http://docs.python.org/library/itertools.html and many others for examples of pages that lack a link). Perhaps putting it in a more conspicuous but still consistent location would be reasonable (the sidebar?). ---------- assignee: docs@python components: Documentation messages: 147973 nosy: Julian, docs@python priority: normal severity: normal status: open title: Provide links to the source code for every module in the documentation type: feature request versions: Python 2.7, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13437> _______________________________________

6 14

[issue11448] docs for HTTPConnection.set_tunnel are ambiguous
by Ryan Kelly 16 Mar '14

16 Mar '14

New submission from Ryan Kelly <ryan(a)rfk.id.au>: The docs for HTTPConnection.set_tunnel(host,port) are ambiguous. They simply say "Set the host and the port for HTTP Connect Tunnelling". But should I specify the address of the server *through* which I want to tunnel, or the address of the *endpoint* of the tunnel? Turns out it's the latter, but I just wasted an hour "debugging" thinking it was the former :-( Attached is a simple doc patch to try to clarify this issue. ---------- assignee: docs@python components: Documentation files: set_tunnel_doc.diff keywords: patch messages: 130396 nosy: docs@python, rfk priority: normal severity: normal status: open title: docs for HTTPConnection.set_tunnel are ambiguous versions: Python 3.3 Added file: http://bugs.python.org/file21056/set_tunnel_doc.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue11448> _______________________________________

8 14

[issue12901] Nest class/methods directives in documentation
by Éric Araujo 15 Mar '14

15 Mar '14

New submission from Éric Araujo <merwok(a)netwok.org>: I picked up a few files in Doc/library and updated their markup to use directives nesting. The attached patch is the result; it’s a lot of changes for small benefit. If we think it’s a good change anyway, I have two questions - Do you think it would be a good idea to have the -checkins emails ignore whitespace changes in some cases? (I’m thinking a magic string in the commit message) - A number of files have a class directive near the top of the file, in the list of all public names, and a later section “XX objects” with the methods and attributes. When this is changed to nested class/methods directives, sometimes the first class directive gets a noindex flag, but I think it should jsut be removed: the index in the sidebar is enough to let people jump to the doc. Do you agree? ---------- assignee: docs@python components: Documentation messages: 143552 nosy: benjamin.peterson, docs@python, eric.araujo, georg.brandl priority: normal severity: normal status: open title: Nest class/methods directives in documentation versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12901> _______________________________________

3 5

[issue12354] packaging.pypi.simple docs use both client and crawler variable, which might be confusing
by Filip Gruszczyński 13 Mar '14

13 Mar '14

New submission from Filip Gruszczyński <gruszczy(a)gmail.com>: In documentation for packaging.pypi.simple in first code snippet crawler variable is created on which further operations will be performed. However in all next snippets there is client variable, which is a little confusing on first sight. This could be consistent throughout the whole page. ---------- assignee: docs@python components: Distutils2, Documentation messages: 138538 nosy: alexis, docs@python, eric.araujo, gruszczy priority: normal severity: normal status: open title: packaging.pypi.simple docs use both client and crawler variable, which might be confusing versions: Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12354> _______________________________________

4 9

[issue15231] update PyPI upload doc to say --no-raw passed to rst2html.py
by Chris Jerdonek 12 Mar '14

12 Mar '14

New submission from Chris Jerdonek <chris.jerdonek(a)gmail.com>: I had an issue whereby my reST long_description wasn't getting rendered as HTML when uploaded to PyPI. Following the instructions here did not work as-is: http://docs.python.org/dev/distutils/uploading.html#pypi-package-display It seems that PyPI passes --no-raw (no HTML allowed) to rst2html.py, in which case the guidance would be better updated to read-- $ python setup.py --long-description | rst2html.py --no-raw > output.html ---------- assignee: docs@python components: Documentation keywords: easy messages: 164445 nosy: cjerdonek, docs@python priority: normal severity: normal status: open title: update PyPI upload doc to say --no-raw passed to rst2html.py versions: Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15231> _______________________________________

5 39

[issue13530] Docs for os.lseek neglect to mention what it returns
by Ned Batchelder 11 Mar '14

11 Mar '14

New submission from Ned Batchelder <ned(a)nedbatchelder.com>: The docs for os.lseek don't make any mention of its return value. I believe it's the new offset in the file, but I'm not sure if there are other subtleties to be mentioned. ---------- assignee: docs@python components: Documentation messages: 148861 nosy: docs@python, nedbat priority: normal severity: normal status: open title: Docs for os.lseek neglect to mention what it returns versions: Python 2.7, Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13530> _______________________________________

9 10

[issue14995] PyLong_FromString documentation should state that the string must be null-terminated
by Ryan Kelly 02 Mar '14

02 Mar '14

New submission from Ryan Kelly <ryan(a)rfk.id.au>: PyLong_FromString will raise a ValueError if the given string doesn't contain a null byte after the digits. For example, this will result in a ValueError char *pend; PyLong_FromString("1234 extra", &pend, 10) While this will successfully read the number and set the pointer to the extra data: char *pend; PyLong_FromString("1234\0extra", &pend, 10) The requirement for a null-terminated string of digits is not clear from the docs. Suggested re-wording attached. ---------- assignee: docs@python components: Documentation files: PyLong_FromString-doc.patch keywords: patch messages: 162242 nosy: docs@python, rfk priority: normal severity: normal status: open title: PyLong_FromString documentation should state that the string must be null-terminated Added file: http://bugs.python.org/file25812/PyLong_FromString-doc.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14995> _______________________________________

2 1

[issue13663] pootle.python.org is outdated.
by INADA Naoki 16 Feb '14

16 Feb '14

New submission from INADA Naoki <songofacandy(a)gmail.com>: I am one of Japanese translate of Python documents. We have done translating Python 2.7 document and will start translating Python 3.2 or 3.3. I want to use sphinx-i18n and pootle to translate. But http://pootle.python.org/ is very outdated. Anyone can update the site? If nobody maintain the site, could I create Python Document project at http://pootle.locamotion.org/ ? ---------- assignee: docs@python components: Documentation messages: 150261 nosy: docs@python, naoki priority: normal severity: normal status: open title: pootle.python.org is outdated. versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13663> _______________________________________

8 10

[issue14515] tempfile.TemporaryDirectory documented as returning object but returns name
by R. David Murray 05 Feb '14

05 Feb '14

New submission from R. David Murray <rdmurray(a)bitdance.com>: The title pretty much says it all. I believe the behavior is correct (more useful than returning an object that is only useful for obtaining the name) even though it is unusual for context managers. In any case there is plenty of code using the existing behavior, so I think this is a doc bug. ---------- assignee: docs@python components: Documentation messages: 157635 nosy: docs@python, r.david.murray priority: normal severity: normal stage: needs patch status: open title: tempfile.TemporaryDirectory documented as returning object but returns name type: behavior versions: Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14515> _______________________________________

6 9

[issue12704] Language References does not specify exception raised by final yield()
by Nikolaus Rath 27 Jan '14

27 Jan '14

New submission from Nikolaus Rath <Nikolaus(a)rath.org>: >From http://docs.python.org/reference/simple_stmts.html#the-yield-statement: "As of Python version 2.5, the yield statement is now allowed in the try clause of a try ... finally construct. If the generator is not resumed before it is finalized (by reaching a zero reference count or by being garbage collected), the generator-iterator’s close() method will be called, allowing any pending finally clauses to execute." This strongly suggests that the last-executed yield statement will raise an exception if the generator is closed. If this is the case, it would be great if the documentation could be extended to say what exception is raised. If this is not the case, it would be great if whatever magic is happening could be documented as well. ---------- assignee: docs@python components: Documentation messages: 141724 nosy: Nikratio, docs@python priority: normal severity: normal status: open title: Language References does not specify exception raised by final yield() type: feature request versions: Python 2.6, Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12704> _______________________________________

8 18

[issue11379] Remove "lightweight" from minidom description
by Stefan Behnel 22 Dec '13

22 Dec '13

New submission from Stefan Behnel <scoder(a)users.sourceforge.net>: http://docs.python.org/library/xml.dom.minidom.html presents MiniDOM as a "Lightweight DOM implementation". The word "lightweight" is easily misunderstood as meaning "efficient" or "memory friendly". MiniDOM is well known to be neither of the two. The first paragraph then continues: """ xml.dom.minidom is a light-weight implementation of the Document Object Model interface. It is intended to be simpler than the full DOM and also significantly smaller. """ Again, "smaller" can be misread as "low memory footprint", whereas it is actually supposed to refer to an incomplete DOM API implementation. And "simpler" is also clearly exaggerated when compared to the alternative ElementTree package. I would like to see this changed and combined with a clear and visible comment that MiniDOM has very high resource profile, e.g. """ 19.7. xml.dom.minidom — Pure Python DOM implementation xml.dom.minidom is a pure Python implementation of the Document Object Model interface, as known from other programming languages. It is intended to provide a smaller API than the full DOM. Note, however, that MiniDOM has a very large memory footprint compared to other Python XML libraries. If you need a fast and memory friendly XML tree implementation with a vastly simpler API, use the xml.etree package instead. """ ---------- assignee: docs@python components: Documentation messages: 129914 nosy: docs@python, scoder priority: normal severity: normal status: open title: Remove "lightweight" from minidom description versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue11379> _______________________________________

12 66

[issue12828] xml.dom.minicompat is not documented
by Sandro Tosi 12 Nov '13

12 Nov '13

New submission from Sandro Tosi <sandro.tosi(a)gmail.com>: There's no documentation for xml.dom.minicompat - it's a public module and it should have (even a brief) doc. ---------- assignee: docs@python components: Documentation messages: 142845 nosy: docs@python, sandro.tosi priority: normal severity: normal status: open title: xml.dom.minicompat is not documented versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12828> _______________________________________

3 3

[issue13515] Consistent documentation practices for security concerns and considerations
by Nick Coghlan 21 Oct '13

21 Oct '13

New submission from Nick Coghlan <ncoghlan(a)gmail.com>: This issue proposes that we adopt and apply some standard practices when documenting modules that have potential security implications and other cross-cutting errors that may affect multiple interfaces within the module. Accordingly, the main target is the "Documenting Python" meta-docs, proposing the addition of a new subsection to the Style Guide, with an update to the subprocess module documentation serving as the exemplar of a new recommended style: ====================== 2.6 Security Considerations (and Other Concerns) ------------------------------------------------ Some modules provided with Python are inherently exposed to security issues (e.g. shell injection vulnerabilities) due to the purpose of the module (e.g. subprocess invocation). Littering the documentation of these modules with red warning boxes for problems that are due to the task at hand, rather than specifically to Python's support for that task, doesn't make for a good reading experience. Instead, these security concerns should be gathered into a dedicated "Security Considerations" section within the module's documentation, and cross-referenced from the documentation of affected interfaces with in-line text similar to "Please refer to the :ref:`security-considerations` section for important information on how to avoid common mistakes". Similarly, if there is a common error that affects many interfaces in a module (e.g. OS level pipe buffers filling up and stalling child processes), these can be documented in a "Common Errors" section and cross-referenced rather than repeated for every affected interface. ====================== (based on the thread at http://mail.python.org/pipermail/python-dev/2011-December/114717.html) ---------- assignee: docs@python components: Documentation messages: 148710 nosy: docs@python, ncoghlan priority: normal severity: normal stage: needs patch status: open title: Consistent documentation practices for security concerns and considerations _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13515> _______________________________________

9 27

[issue14502] Document better what happens on releasing an unacquired lock
by Georg Brandl 13 Oct '13

13 Oct '13

New submission from Georg Brandl <georg(a)python.org>: >From docs(a)python.org: """ I recently ran into a situation where I could not be certain that a lock was currently in the acquired state. I checked the documentation to determine what would happen if I attempted to release a lock that was already released, and saw an ominous warning of "Do not call this method when the lock is unlocked." Needing to know what would happen, I cautiously tested it out. I half expected my computer to explode as I released a lock for the second time, but was pleased to see it raise a 'thread.error' exception which could be caught and handled. I generally expect the documentation to tell me what will happen if I do something invalid. In this case the documentation should indicate that a thread.error will be raised if you release an unlocked lock. """ I agree: if we know that a ThreadError will always be raised in this instance, we should document it as such. ---------- assignee: docs@python components: Documentation messages: 157544 nosy: docs@python, georg.brandl, pitrou priority: normal severity: normal status: open title: Document better what happens on releasing an unacquired lock versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14502> _______________________________________

9 23

[issue11120] threading.Thread.daemon Documentation Incomplete
by cardinalbiggles 13 Oct '13

13 Oct '13

New submission from cardinalbiggles <jmandersen(a)gmail.com>: In the threading module, the documentation for Thread.isDaemon()/Thread.setDaemon() indicates they are the old API for Thread.daemon, which does not indicate the version in which it was introduced (2.6 I believe). Additionally, the documentation for Thread.setDaemon() should at least include the daemonic parameter, if not the full usage documentation for those targeting older versions. Targeting Python 2.4, and being unable to (as) efficiently navigate the old documentation site, I have come to rely on the various 'Changed/New in version 2.X' messages in the current documentation. This caused some confusion on my part. ---------- assignee: docs@python components: Documentation messages: 127927 nosy: cardinalbiggles, docs@python priority: normal severity: normal status: open title: threading.Thread.daemon Documentation Incomplete type: feature request versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue11120> _______________________________________

2 1

[issue14486] Add some versionchanged notes in threading docs
by Nick Coghlan 13 Oct '13

13 Oct '13

New submission from Nick Coghlan <ncoghlan(a)gmail.com>: A (very) minor irritation discovered today - the PEP 8 style names were added to the threading.Thread API in 2.6, but the only notice of this is up at the top of the module docs. Some embedded notices like: ..versionchanged:: 2.6 Added PEP 8 compliant interfaces. See note at top of page. might be helpful. ---------- assignee: docs@python components: Documentation keywords: easy messages: 157451 nosy: docs@python, ncoghlan priority: low severity: normal stage: needs patch status: open title: Add some versionchanged notes in threading docs type: enhancement versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14486> _______________________________________

3 2

[issue13744] raw byte strings are described in a confusing way
by Barry A. Warsaw 13 Oct '13

13 Oct '13

New submission from Barry A. Warsaw <barry(a)python.org>: The lexical analysis documentation says this: http://docs.python.org/py3k/reference/lexical_analysis.html?highlight=raw%2… "Bytes literals are always prefixed with 'b' or 'B';..." "Both string and bytes literals may optionally be prefixed with a letter 'r' or 'R';..." But that would lead you to believe that to get raw byte strings you should use rb"foo". In fact, that's a SyntaxError in Python 2.6+ and Python 3. What *does* work though is br"foo". Either Python should accept both spellings (harder) or the documentation should make it clear that the 'b' must preceded the 'r'. ---------- assignee: docs@python components: Documentation messages: 150936 nosy: barry, docs@python priority: normal severity: normal status: open title: raw byte strings are described in a confusing way versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13744> _______________________________________

7 11

[issue13915] Update Tutorial 6.1.3 for PEP 3145
by Terry J. Reedy 12 Oct '13

12 Oct '13

New submission from Terry J. Reedy <tjreedy(a)udel.edu>: http://docs.python.org/py3k/tutorial/modules.html#compiled-python-files needs to be updated for 3.2+ to reflect http://python.org/dev/peps/pep-3147/ The first sentence is still technically correct, but finding x.pyc in the same directory as x.py is now an anomaly, so that sentence, revised, should be near the bottom. Otherwise, the text should say that the default is to put x.<version>.pyc in __pycache__, where <version> is, for instance, 'cpython-32'. Note that this allows other implementations and other versions of cpython to use the same .py file. I do not know if there is anywhere else that this info is or should be. Using Python?. ---------- assignee: docs@python components: Documentation messages: 152415 nosy: docs@python, terry.reedy priority: normal severity: normal stage: needs patch status: open title: Update Tutorial 6.1.3 for PEP 3145 type: behavior versions: Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13915> _______________________________________

5 5

[issue13833] No documentation for PyStructSequence
by Torsten Landschoff 12 Oct '13

12 Oct '13

New submission from Torsten Landschoff <t.landschoff(a)gmx.net>: While writing a C extension I wanted to create a namedtuple like object as os.statvfs and friends do. I was unable to find a simple way to do this from C and was wondering how the posixmodule does it. It turned out that there is a PyStructSequence type for this. It would be nice to have it documented. First draft for the documentation update attached. ---------- assignee: docs@python components: Documentation files: structseq_doc.diff keywords: patch messages: 151657 nosy: docs@python, torsten priority: normal severity: normal status: open title: No documentation for PyStructSequence type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file24280/structseq_doc.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13833> _______________________________________

3 2

[issue13905] Built-in Types Comparisons should mention rich comparison methods
by Catalin Iacob 12 Oct '13

12 Oct '13

New submission from Catalin Iacob <iacobcatalin(a)gmail.com>: In 2.7 the Comparisons section of stdtypes.rst only talks about __cmp__ and never mentions the rich comparison methods: "Instances of a class normally compare as non-equal unless the class defines the __cmp__() method. Refer to Basic customization) for information on the use of this method to effect object comparisons." The first sentence is false, instances can also compare as equal if they define __eq__. And since __cmp__ is gone in Python3, I think the rich comparison methods should at least be mentioned, or even emphasized over __cmp__ to help people write more forward compatible code. ---------- assignee: docs@python components: Documentation messages: 152254 nosy: catalin.iacob, docs@python priority: normal severity: normal status: open title: Built-in Types Comparisons should mention rich comparison methods type: enhancement versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13905> _______________________________________

2 2

[issue13026] Dis module - documentation of MAKE_FUNCTION
by Arnaud Delobelle 12 Oct '13

12 Oct '13

New submission from Arnaud Delobelle <arnodel(a)googlemail.com>: The description of the opcode MAKE_FUNCTION in the dis module document is out of date. It still describes the 2.X version of the opcode: """ MAKE_FUNCTION(argc) Pushes a new function object on the stack. TOS is the code associated with the function. The function object is defined to have argc default parameters, which are found below TOS. """ According to http://hg.python.org/cpython/file/default/Python/ceval.c#l2684: 2684 int posdefaults = oparg & 0xff; 2685 int kwdefaults = (oparg>>8) & 0xff; 2686 int num_annotations = (oparg >> 16) & 0x7fff; So the documentation should read something like """ MAKE_FUNCTION(argc) Pushes a new function object on the stack. TOS is the code associated with the function. The function object is defined to have argc & 0xFF positional default parameters, (argc >> 8) & 0xFF keyword only default parameters, and (argc >> 16) & 0x7FFF parameter annotations which are push below TOS in this order. For each keyword only default, the name of the parameter is pushed just below its default value. On top of all the annotations, a tuple is pushed listing the parameter names for these annotations. """ ---------- assignee: docs@python components: Documentation messages: 144393 nosy: arno, docs@python, terry.reedy priority: normal severity: normal status: open title: Dis module - documentation of MAKE_FUNCTION versions: Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13026> _______________________________________

4 8

[issue13203] Doc: say id() is only useful for existing objects
by Terry J. Reedy 12 Oct '13

12 Oct '13

New submission from Terry J. Reedy <tjreedy(a)udel.edu>: Newbies too often do something like (3.2.2, ) >>> id(getattr(x, 'pop')) == id(x.pop) True and get confused by the (invalid) result, whereas >>> a,b=getattr(x, 'pop'),x.pop >>> id(a)==id(b) False works properly. I think we should add a sentence or two or three to the id() doc, such as Since a newly created argument object is either destroyed or becomes inaccessible before the function returns, *id(obj)* is only useful and valid if *obj* exists prior to the call and therefore after its return. The value of an expression such as *id(666)== id(667)* is arbitrary and meaningless. The id of the first int object might or might not be reused for the second one. ---------- assignee: docs@python components: Documentation messages: 145743 nosy: docs@python, terry.reedy priority: normal severity: normal status: open title: Doc: say id() is only useful for existing objects versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13203> _______________________________________

6 10

[issue11009] urllib.splituser is not documented
by anatoly techtonik 08 Oct '13

08 Oct '13

New submission from anatoly techtonik <techtonik(a)gmail.com>: I'm studying old code that uses urllib.splituser() call and can't find description of this function in Python 2.6.6 docs. ---------- assignee: docs@python components: Documentation messages: 127047 nosy: docs@python, techtonik priority: normal severity: normal status: open title: urllib.splituser is not documented versions: Python 2.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue11009> _______________________________________

6 8

[issue15863] Fine-grained info about Python versions which support changes introduced in micro releases
by Alexander Konovalenko 08 Oct '13

08 Oct '13

New submission from Alexander Konovalenko: Some security fixes and bug fixes that are simultaneously issued for multiple Python versions require changes to the documentation. I'm now looking at the hash randomization vulnerability that was fixed in 2.6.8 and 2.7.3. The docs always mention the release in which a new feature was added. That's great. But for a security fix such as the bug in question, the set of versions which support it doesn't look like "2.x.y or later". The documentation for the -R command-line option and the PYTHONHASHSEED environment variable says "New in version 2.6.8". A reader who is not familiar with the context would infer that those feature are supported in Python 2.7 through 2.7.2, which is not the case. The docs should say "New in version 2.6.8 and 2.7.3". http://docs.python.org/using/cmdline.html#cmdoption-R http://docs.python.org/using/cmdline.html#envvar-PYTHONHASHSEED The documentation for the sys.flags.hash_randomization attribute says "New in version 2.7.3". Again, that leaves out the version 2.6.8 and future versions in the 2.6.x branch, which presumably support the new attribute. The docs should say "New in version 2.6.8 and 2.7.3". http://docs.python.org/library/sys.html#sys.flags Disclaimer: I did not test the relevant micro releases to see whether they actually support those features. Just checked the release dates and applied common sense. If you know of any other micro release bugfixes that were mentioned in the docs, the same considerations apply to them. Please verify the docs are correct, fix them or file appropriate bugs. ---------- assignee: docs@python components: Documentation messages: 169841 nosy: alexkon, docs@python priority: normal severity: normal status: open title: Fine-grained info about Python versions which support changes introduced in micro releases versions: Python 2.6, Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15863> _______________________________________

4 6

[issue15455] index entries not showing up in glossary
by Chris Jerdonek 08 Oct '13

08 Oct '13

New submission from Chris Jerdonek <chris.jerdonek(a)gmail.com>: I haven't tracked down the reason for this, but certain index entries seem to be getting skipped in the Glossary. If you view source on the Glossary page and search for "index-": http://docs.python.org/dev/glossary.html You will find that it skips from 'index-2' to 'index-5'. Only :pep: index entries are getting included even though the Glossary's rst file contains explicit index directives (where 'index-3' and 'index-4' would otherwise be). I tried some experiments, and this seems to occur even if the index directive text does not match the name of the Glossary term. ---------- assignee: docs@python components: Documentation messages: 166467 nosy: cjerdonek, docs@python priority: normal severity: normal status: open title: index entries not showing up in glossary type: behavior versions: Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15455> _______________________________________

3 3

[issue15264] PyErr_SetFromErrnoWithFilenameObject() undocumented
by Antoine Pitrou 08 Oct '13

08 Oct '13

New submission from Antoine Pitrou <pitrou(a)free.fr>: Title says it all. ---------- assignee: docs@python components: Documentation, Interpreter Core messages: 164736 nosy: docs@python, pitrou priority: normal severity: normal stage: needs patch status: open title: PyErr_SetFromErrnoWithFilenameObject() undocumented type: behavior versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15264> _______________________________________

2 1

[issue13867] misleading comment in weakrefobject.h
by Jim Jewett 08 Oct '13

08 Oct '13

New submission from Jim Jewett <jimjjewett(a)gmail.com>: http://hg.python.org/cpython/file/fec45282dc28/Include/weakrefobject.h#l54 The comment makes sense -- but doesn't appear to be true, so perhaps it is the macro that should change. /* This macro calls PyWeakref_CheckRef() last since that can involve a function call; this makes it more likely that the function call will be avoided. */ #define PyWeakref_Check(op) \ (PyWeakref_CheckRef(op) || PyWeakref_CheckProxy(op)) ---------- assignee: docs@python components: Documentation, Extension Modules messages: 151983 nosy: Jim.Jewett, docs@python priority: normal severity: normal status: open title: misleading comment in weakrefobject.h _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13867> _______________________________________

4 5

[issue14224] packaging: path description of resources is mixed up
by Johannes Kolb 08 Oct '13

08 Oct '13

New submission from Johannes Kolb <johannes.kolb(a)gmx.net>: The documentation for "files" section of the setup.cfg file causes confusion: The examples don't match the description. Obviously the order of "destination" and "source" part in the generated filenames was mixed up in some places. ---------- assignee: docs@python components: Documentation files: packaging-docfixes.diff keywords: patch messages: 155123 nosy: docs@python, jokoala priority: normal severity: normal status: open title: packaging: path description of resources is mixed up type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file24754/packaging-docfixes.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14224> _______________________________________

3 2

[issue13436] compile() doesn't work on ImportFrom with level=None
by Janosch Gräf 08 Oct '13

08 Oct '13

New submission from Janosch Gräf <janosch.graef(a)gmx.net>: The documentation for ast says that arguments that are marked with a '?' in the abstract grammar are optional and can therefore be None. When I try to compile a Module node which contains an ImportFrom node with attribute level=None compile() throws an exception: Module(body=[ImportFrom(module='time', names=[alias(name='sleep', asname=None), alias(name='time', asname=None)], level=None, lineno=0, col_offset=0)]) Traceback (most recent call last): File "g0.py", line 423, in <module> p.main() File "g0.py", line 65, in main self.reproduce("g1.pyc") File "g0.py", line 85, in reproduce co = self.generate_bytecode(st, genome) File "g0.py", line 243, in generate_bytecode co = compile(st, id, "exec") ValueError: invalid integer value: �� So, I tried to set level=0: Module(body=[ImportFrom(module='time', names=[alias(name='sleep', asname=None), alias(name='time', asname=None)], level=0, lineno=0, col_offset=0)]) and everything worked fine. BTW: The unprintable bytes in the error message are: ef bf bd ef bf bd ef bf bd ef bf bd ef bf bd ef bf bd ef bf bd ef bf bd ---------- assignee: docs@python components: Documentation, Interpreter Core messages: 147972 nosy: Janosch.Gräf, docs@python priority: normal severity: normal status: open title: compile() doesn't work on ImportFrom with level=None type: behavior versions: Python 3.1 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13436> _______________________________________

6 9

[issue12162] Documentation about re \number
by Seth Troisi 06 Oct '13

06 Oct '13

New submission from Seth Troisi <braintwo(a)gmail.com>: It would be nice to clarify re documentation on how to use \number. current documentation lists three half examples: "(.+) \1 matches 'the the' or '55 55', but not 'the end' (note the space after the group)." This is rather confusing (at least to me) as it might be assumed that re.search("(.+) \1", "the the") would return a match, which it does not. A better example would be re.search("(\w+) \\1", "the the") which does match. the other confusing portion is the requirement of the second "\" to make it match. I would think that a quick example below the text would help. >>> re.search("(\w+) \\1", "can you do the can can?") # \\1 matches the second can at the end of the sentence <_sre.SRE_Match object at ...> This is my first python issue and if I have misfiled or left out some information please tell me how to proceed. ---------- assignee: docs@python components: Documentation messages: 136708 nosy: Seth.Troisi, docs@python priority: normal severity: normal status: open title: Documentation about re \number type: behavior _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12162> _______________________________________

5 8

[issue11789] Extend upon metaclass/type class documentation, here: zope.interface and usage of instances of classes as base classes
by Carsten Klein 06 Oct '13

06 Oct '13

New submission from Carsten Klein <carsten.klein(a)axn-software.de>: In zope.interface, you have something the following construct: class InterfaceBase: pass Interface = InterfaceBase() Using the above Interface as a derivation base for your own classes, will make that instance a type derived class: class IFoo(Interface): pass type(IFoo) -> Interface type(Interface) -> type I wonder why this behavior is not documented in the official documentation, or at least, I was unable to find it there... ---------- assignee: docs@python components: Documentation messages: 133173 nosy: carsten.klein, docs@python priority: normal severity: normal status: open title: Extend upon metaclass/type class documentation, here: zope.interface and usage of instances of classes as base classes type: feature request versions: Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue11789> _______________________________________

2 2

[issue11585] Documentation 1.8 shows Python 2 example
by Clive Darke 06 Oct '13

06 Oct '13

New submission from Clive Darke <clive.darke(a)qa.com>: Python 3.2 version attached ---------- assignee: docs@python components: Documentation files: parrot.c messages: 131246 nosy: cdarke, docs@python priority: normal severity: normal status: open title: Documentation 1.8 shows Python 2 example versions: Python 3.1, Python 3.2 Added file: http://bugs.python.org/file21267/parrot.c _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue11585> _______________________________________

2 2

[issue14101] example function in tertools.count is misindented
by Zbyszek Szmek 06 Oct '13

06 Oct '13

New submission from Zbyszek Szmek <zbyszek(a)in.waw.pl>: Indentation is broken. diff --git a/Modules/itertoolsmodule.c b/Modules/itertoolsmodule.c --- a/Modules/itertoolsmodule.c +++ b/Modules/itertoolsmodule.c @@ -3221,10 +3221,10 @@ Return a count object whose .__next__() method returns consecutive values.\n\ Equivalent to:\n\n\ def count(firstval=0, step=1):\n\ - x = firstval\n\ - while 1:\n\ - yield x\n\ - x += step\n"); + x = firstval\n\ + while 1:\n\ + yield x\n\ + x += step\n"); ---------- assignee: docs@python components: Documentation, Library (Lib) files: itertools-count-indentation.diff keywords: patch messages: 154084 nosy: docs@python, zbysz priority: normal severity: normal status: open title: example function in tertools.count is misindented type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file24618/itertools-count-indentation.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14101> _______________________________________

4 3

[issue15432] gzip.py: mtime argument only since python 2.7
by Geir Ove Myhr 06 Oct '13

06 Oct '13

New submission from Geir Ove Myhr <gomyhr(a)gmail.com>: In the gzip documentation (http://docs.python.org/library/gzip.html) a note should be added that the mtime option was added in Python 2.7. The patch which adds the option (http://svn.python.org/view?view=revision&revision=68319) is not included in Python 2.6.5. ---------- assignee: docs@python components: Documentation messages: 166214 nosy: docs@python, gomyhr priority: normal severity: normal status: open title: gzip.py: mtime argument only since python 2.7 versions: Python 2.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15432> _______________________________________

2 2

[issue15228] os.utime() docs not clear on behavior on nonexistant files
by Daniel Grace 06 Oct '13

06 Oct '13

New submission from Daniel Grace <thisgenericname(a)gmail.com>: The documentation for os.utime() at http://docs.python.org/py3k/library/os.html#os.utime states: "Set the access and modified times of the file specified by path. [...] The effect is similar to running the Unix program touch on the path.)" Unlike 'touch', os.utime() will not create an empty file if called on a file that does not exist. IMO the current behavior is correct, but the comparison of os.utime() to touch implies that it would create empty files. I suggest clarifying the documentation to emphasize that os.utime() will not create new files and raises OSError in the event that the file does not exist. ---------- assignee: docs@python components: Documentation messages: 164422 nosy: dewin, docs@python priority: normal severity: normal status: open title: os.utime() docs not clear on behavior on nonexistant files type: enhancement _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15228> _______________________________________

4 4

[issue11807] Documentation of add_subparsers lacks information about parametres
by Filip Gruszczyński 06 Oct '13

06 Oct '13

New submission from Filip Gruszczyński <gruszczy(a)gmail.com>: In argparse documentation parametres of add_subparsers are not listed. And yet there are some really useful parametres like parser_class. It would be useful, it they were described there well and one wouldn't have to look into the code to find them :-) I'll be happy to provide documentation patch tomorrow. ---------- assignee: docs@python components: Documentation messages: 133379 nosy: docs@python, gruszczy priority: normal severity: normal status: open title: Documentation of add_subparsers lacks information about parametres versions: Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue11807> _______________________________________

3 8

[issue15213] _PyOS_URandom documentation
by Christian Heimes 06 Oct '13

06 Oct '13

New submission from Christian Heimes <lists(a)cheimes.de>: The comment for Python/random.c:_PyOS_URandom() states > Fill buffer with size pseudo-random bytes, not suitable for cryptographic use, from the operating random number generator (RNG). which is not correct as all paths use a RNG that is suitable for most cryptographic purposes except long living private keys for asymmetric encryption. Also the function isn't documented although it's an official API function and plays a vital role on the new hash randomization. ---------- assignee: docs@python components: Documentation messages: 164218 nosy: christian.heimes, docs@python, haypo, pitrou priority: low severity: normal status: open title: _PyOS_URandom documentation versions: Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15213> _______________________________________

5 6

[issue12350] Improve stat_result.st_blocks and st_blksize documentation
by Lars Wirzenius 06 Oct '13

06 Oct '13

New submission from Lars Wirzenius <liw(a)liw.fi>: Attached patch adds a few words to the os.stat documentation for the st_blocks and st_blksize fields to clarify them. ---------- assignee: docs@python components: Documentation files: stat_result.patch keywords: patch messages: 138467 nosy: docs@python, liw priority: normal severity: normal status: open title: Improve stat_result.st_blocks and st_blksize documentation versions: Python 2.7 Added file: http://bugs.python.org/file22382/stat_result.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12350> _______________________________________

4 10

[issue11163] iter() documentation code doesn't work
by Michael Grazebrook 11 Sep '13

11 Sep '13

New submission from Michael Grazebrook <michael(a)grazebrook.com>: This code fragment from the documentation of iter() doesn't work as intended. Change "STOP" to "STOP\n". Maybe also check for EOF as it hangs. with open("mydata.txt") as fp: for line in iter(fp.readline, "STOP"): process_line(line) Or maybe this makes a better example because it's clearer wha'ts going on: square_generator = (i * i for i in range(100000)) for n in iter( square_generator.next, 144): print n ---------- assignee: docs@python components: Documentation messages: 128238 nosy: docs@python, mgrazebrook priority: normal severity: normal status: open title: iter() documentation code doesn't work type: behavior versions: Python 2.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue11163> _______________________________________

6 10

[issue15233] atexit: guarantee order of execution of registered functions?
by Georg Brandl 21 Aug '13

21 Aug '13

New submission from Georg Brandl <georg(a)python.org>: Currently, the atexit docs state "The order in which the functions are called is not defined" in the introduction and "all functions registered are called in last in, first out order" in the docs of the atexit() function. While the latter is correct, I don't think we should guarantee that behaviour by documenting it. Suggestions? ---------- assignee: docs@python components: Documentation messages: 164454 nosy: docs@python, georg.brandl, loewis, pitrou priority: normal severity: normal status: open title: atexit: guarantee order of execution of registered functions? versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15233> _______________________________________

8 23

[issue15939] make *.rst files in Doc/ parseable by doctest
by Chris Jerdonek 17 Aug '13

17 Aug '13

New submission from Chris Jerdonek: Currently, when trying to parse the *.rst files in the Doc/ folder (i.e. not actually running them but simply generating unittest.TestCase instances from them by passing them to doctest.DocFileSuite()), five files yield errors. This issue is to make it so that all of the *.rst files in our Doc/ folder are at least parseable by doctest without error. I will submit a patch. Below are the errors that currently occur: (1) test fdoc:library/ctypes.rst crashed -- Traceback (most recent call last): ... ValueError: line 55 of the doctest for ctypes.rst has an invalid option: '+WINDOWS' (2) test fdoc:library/doctest.rst crashed -- Traceback (most recent call last): ... ValueError: line 1592 of the docstring for doctest.rst has inconsistent leading whitespace: ' """))' (3) test fdoc:library/multiprocessing.rst crashed -- Traceback (most recent call last): ... ValueError: line 1016 of the docstring for multiprocessing.rst lacks blank after >>>: '>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>' (4) test fdoc:whatsnew/2.4.rst crashed -- Traceback (most recent call last): ... ValueError: line 1422 of the docstring for 2.4.rst lacks blank after >>>: ' >>>"""' (5) test fdoc:whatsnew/2.7.rst crashed -- Traceback (most recent call last): ... ValueError: line 1531 of the docstring for 2.7.rst lacks blank after .: ' ...' ---------- assignee: docs@python components: Documentation messages: 170441 nosy: cjerdonek, docs@python priority: normal severity: normal status: open title: make *.rst files in Doc/ parseable by doctest versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15939> _______________________________________

2 11

[issue12645] test.support. import_fresh_module - incorrect doc
by Eli Bendersky 11 Aug '13

11 Aug '13

New submission from Eli Bendersky <eliben(a)gmail.com>: >From Ezio Melotti's email to python-dev: diff --git a/Doc/library/test.rst b/Doc/library/test.rst --- a/Doc/library/test.rst +++ b/Doc/library/test.rst @@ -447,7 +447,7 @@ Module and package deprecation messages are suppressed during this import if *deprecated* is ``True``. - This function will raise :exc:`unittest.SkipTest` is the named module + This function will raise :exc:`unittest.SkipTest` if the named module Actually I think this is no longer true. import_fresh_module raises an ImportError if *name* can't be imported, or returns None if the fresh module is not found. Its use case is to enable or block accelerations for modules that optionally provide one. All the modules that currently use import_fresh_module are (afaik) always available (json, warnings, heapq), so raising SkipTest when the module is missing is not useful now. It returns None in the case an acceleration is missing, so e.g. in "cjson = import_fresh_module('json', fresh=['_json'])" cjson will be None and it will be possible to do things like @skipUnless(cjson, 'requires _json'). Here raising an ImportError will defeat (part of) the purpose of the function, i.e. avoiding: try: import _json except ImportError: _json = None and raising a SkipTest when the accelerations are missing is not an option if there are other tests (e.g. the tests for the Python implementation). These changes come from http://hg.python.org/cpython/rev/c1a12a308c5b . Before the change import_fresh_module was still returning the module (e.g. json) even when the acceleration (fresh=['_json']) was missing, and the C tests were run twice using the same pure-python module used for the Py ones. The typo and the wrong doc is also on 2.7. ---------- assignee: docs@python components: Documentation keywords: easy messages: 141255 nosy: docs@python, eli.bendersky, ezio.melotti priority: normal severity: normal status: open title: test.support. import_fresh_module - incorrect doc versions: Python 2.7, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12645> _______________________________________

5 9

[issue10434] Document the rules for "public names"
by Alexander Belopolsky 01 Aug '13

01 Aug '13

New submission from Alexander Belopolsky <belopolsky(a)users.sourceforge.net>: As discussed in "Breaking undocumented API" thread [1] on python-dev, a definition of "public names" is buried deep in the language reference manual: """ The public names defined by a module are determined by checking the module’s namespace for a variable named __all__; if defined, it must be a sequence of strings which are names defined or imported by that module. The names given in __all__ are all considered public and are required to exist. If __all__ is not defined, the set of public names includes all names found in the module’s namespace which do not begin with an underscore character ('_'). __all__ should contain the entire public API. It is intended to avoid accidentally exporting items that are not part of the API (such as library modules which were imported and used within the module). """ [2] It has been argued that this is not the authoritative definition and alternatives have been suggested such as "any name that does not begin with an underscore except imported modules." mportant for the users and developers of cpython and other python implementations to know what names they can rely upon to stay defined between releases, the rules for "public names" should be documented. I agree that the library manual is a more appropriate place for such documentation. The definition should include the naming conventions and the set of promises that Python makes about public name availability in the future releases. [1] http://mail.python.org/pipermail/python-dev/2010-November/105490.html [2] http://docs.python.org/reference/simple_stmts.html ---------- assignee: docs@python components: Documentation messages: 121297 nosy: belopolsky, docs@python priority: normal severity: normal stage: needs patch status: open title: Document the rules for "public names" versions: Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10434> _______________________________________

6 7

[issue15130] remove redundant paragraph in socket howto
by Tshepang Lekhonkhobe 25 Jul '13

25 Jul '13

New submission from Tshepang Lekhonkhobe <tshepang(a)gmail.com>: same text used on Abstract is used in the beginning of the main text ---------- assignee: docs@python components: Documentation files: redundancy.diff keywords: patch messages: 163364 nosy: docs@python, tshepang priority: normal severity: normal status: open title: remove redundant paragraph in socket howto versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file26076/redundancy.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15130> _______________________________________

4 4

[issue11908] Weird `slice.stop or sys.maxint`
by Ram Rachum 11 Jul '13

11 Jul '13

New submission from Ram Rachum <cool-rr(a)cool-rr.com>: In the documentation for `itertools.islice` I see this line: it = iter(xrange(s.start or 0, s.stop or sys.maxint, s.step or 1)) Is it really okay to do `s.stop or sys.maxint`? I'm assuming this was targeting `None`, but what if `s.stop == 0`? And `s.step` could (pathologically) be `0` too, no? ---------- assignee: docs@python components: Documentation messages: 134276 nosy: cool-RR, docs@python priority: normal severity: normal status: open title: Weird `slice.stop or sys.maxint` type: behavior versions: Python 2.5, Python 2.6, 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/issue11908> _______________________________________

8 13

[issue14206] multiprocessing.Queue documentation is lacking important details
by Garrett Moore 02 Jul '13

02 Jul '13

New submission from Garrett Moore <garrettmoore(a)gmail.com>: 1) If cancel_join_thread() is called, data may be lost. This is not explicitly stated. I had multiple writers put() data in a Queue, and wanted to have the workers finish before I began consuming the data. This caused a deadlock because my Queue was not empty, and it seemed like the a way to force my workers finish was to use cancel_join_thread(). This caused data loss. 2) multiprocessing.Queue states "The Queue class is a near clone of Queue.Queue." Queue.Queue states "If maxsize is less than or equal to zero, the queue size is infinite." mp.Queue provides no information on queue size. It is reasonable to assume then that it inherits the property of Queue.Queue. After discussion on IRC, it seems that mp.Queue maximum size is implementation-dependent and likely relies on how much data Pipes can hold on your platform. If this is the case there should be some mention of the fact that mp.Queue does NOT function like Queue.Queue does for maximum size. ---------- assignee: docs@python components: Documentation messages: 154995 nosy: Garrett.Moore, docs@python priority: normal severity: normal status: open title: multiprocessing.Queue documentation is lacking important details versions: Python 2.6, Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14206> _______________________________________

4 4

[issue12716] Reorganize os docs for files/dirs/fds
by Benjamin Peterson 29 Jun '13

29 Jun '13

New submission from Benjamin Peterson <benjamin(a)python.org>: Right now many of the os function docs are split up into "Files and directories" and "file descriptor operations". This means, for example, that fchmod() and fchmodat() are in a different section than chmod(). It would make more sense to organize the docs such that functions that do the same thing are right next to each other. ---------- assignee: docs@python components: Documentation keywords: easy messages: 141820 nosy: benjamin.peterson, docs@python priority: low severity: normal status: open title: Reorganize os docs for files/dirs/fds versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12716> _______________________________________

7 9

[issue15818] multiprocessing documentation of Process.exitcode
by Josh Kupershmidt 24 Jun '13

24 Jun '13

New submission from Josh Kupershmidt: [I tried to send this as an email to docs(a)python.org yesterday, but it seems to have gotten eaten, as I don't see the message in the archives.] Hi all, The documentation for the multiprocessing module claims: | Note that the start(), join(), is_alive() and exit_code methods | should only be called by the process that created the process object. Two problems with this description: 1. "exit_code" should be spelled "exitcode" 2. exitcode is an attribute of the Process class, not a method as claimed, since the underlying method is decorated with @property Also, aside from the above documentation issues, if it is true that it's not safe to query the exitcode from a separate process, should the exitcode property method include a check like so: assert self._parent_pid == os.getpid(), 'can only test a child process' since start(), join(), and is_alive() all perform this check? ---------- assignee: docs@python components: Documentation messages: 169428 nosy: docs@python, schmiddy priority: normal severity: normal status: open title: multiprocessing documentation of Process.exitcode versions: Python 2.7, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15818> _______________________________________

3 3

[issue14015] surrogateescape largely missing from documentation
by Jim Jewett 16 Jun '13

16 Jun '13

New submission from Jim Jewett <jimjjewett(a)gmail.com>: Recent discussion on the mailing lists and in http://bugs.python.org/issue13997 make it clear that the best way to get python2 results for "ASCII-in-the-parts-I-might-process-or-change" is to replace f = open(fname) with f = open(fname, encoding="ascii", errors="surrogateescape") Unfortunately, surrogateescape (let alone this recipe) is not easily discoverable. http://docs.python.org/dev/library/functions.html#open lists 5 error-handlers -- but not this one. It says that other error handlers are possible if they are registered with http://docs.python.org/dev/library/codecs.html#codecs.register_error but I haven't found a way to determine which error handlers are already registered. The codecs.register (as opposed to register_error) documentation does list it as a possible value, but that is the only reference. The other 5 error handlers are also available as module-level functions within the codecs module, and have their own documenation sections within http://docs.python.org/dev/library/codecs.html Neither help(open) nor import codecs; help(codecs) provides any hints of the existence of surrogateescape. Both explicitly suggest that it does not exist, by enumerating other values. ---------- assignee: docs@python components: Documentation, Unicode messages: 153359 nosy: Jim.Jewett, docs@python, ezio.melotti priority: normal severity: normal status: open title: surrogateescape largely missing from documentation versions: Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14015> _______________________________________

5 5

[issue14616] subprocess docs should mention pipes.quote/shlex.quote
by Éric Araujo 28 May '13

28 May '13

New submission from Éric Araujo <merwok(a)netwok.org>: The warning at http://docs.python.org/library/subprocess#frequently-used-arguments should IMO recommend using shlex.quote. Even if it strongly advises against using shell=True, there are people who need or want to use it, so let’s give them a pointer to the quote function. For older versions, I think we should talk about pipes.quote; even if it’s not documented in library/pipes, it is there, it is known and it is used, so I see no harm in mentioning it (with due mention that it’s only semi-official and that it becomes public in 3.3). ---------- assignee: docs@python components: Documentation messages: 158641 nosy: docs@python, eric.araujo priority: normal severity: normal status: open title: subprocess docs should mention pipes.quote/shlex.quote versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14616> _______________________________________

6 19

[issue14009] Clearer documentation for cElementTree
by Éric Araujo 20 May '13

20 May '13

New submission from Éric Araujo <merwok(a)netwok.org>: This patch should clarify how to use cElementTree usage, as well as improving indexing. ---------- assignee: docs@python components: Documentation messages: 153338 nosy: docs@python, eli.bendersky, eric.araujo priority: normal severity: normal stage: commit review status: open title: Clearer documentation for cElementTree versions: Python 2.7, Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14009> _______________________________________

4 13

[issue14878] send statement from PEP342 is poorly documented.
by Stephen Lacy 10 May '13

10 May '13

New submission from Stephen Lacy <slacy(a)slacy.com>: There's reasonable documentation of the yield statement for most python versions under Section 6: Simple Statements, particularly 6.8 "The Yield Statement" (http://docs.python.org/release/2.7/reference/simple_stmts.html#the-yield-st…) But, there's no mention of the return value of the yield statement, or that the send statement even exists. It's mentioned in passing here under "PEP342 New Generator Features" (http://docs.python.org/whatsnew/2.5.html#pep-342-new-generator-features) but should be given fuller explanation and cross-linking from the yield statement documentation. It's also mentioned a bit here: http://docs.python.org/howto/functional.html#passing-values-into-a-generator but again, not under the language documentation itself. ---------- assignee: docs@python components: Documentation messages: 161320 nosy: Stephen.Lacy, docs@python priority: normal severity: normal status: open title: send statement from PEP342 is poorly documented. versions: Python 2.6, 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/issue14878> _______________________________________

6 6

[issue14187] add "annotation" entry to Glossary
by Chris Rebert 06 May '13

06 May '13

New submission from Chris Rebert <pybugs(a)rebertia.com>: The Glossary should include an entry for "annotation" and/or "function annotation" regarding the language feature introduced by PEP 3107. ---------- assignee: docs@python components: Documentation messages: 154852 nosy: cvrebert, docs@python priority: normal severity: normal status: open title: add "annotation" entry to Glossary versions: Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14187> _______________________________________

8 23

[issue12825] Missing and incorrect link to a command line option.
by Kyle Simpson 23 Apr '13

23 Apr '13

New submission from Kyle Simpson <illwhipyou(a)gmail.com>: The documentation for the runpy module has a link to the -m command line option. In version 2.7.2 of the docs, the link doesn't exist. http://docs.python.org/release/2.7/library/runpy.html http://docs.python.org/release/2.7.2/library/runpy.html If you run touch library/runpy.rst make html then the link is created, but with an anchor of "cmdoption-unittest-discover-m" instead of "cmdoption-m". http://docs.python.org/release/2.7.2/using/cmdline.html#cmdoption-unittest-… ---------- assignee: docs@python components: Documentation messages: 142797 nosy: Kyle.Simpson, docs@python priority: normal severity: normal status: open title: Missing and incorrect link to a command line option. versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12825> _______________________________________

2 3

[issue15575] Tutorial is unclear on multiple imports of a module.
by Roy Smith 21 Apr '13

21 Apr '13

New submission from Roy Smith: Opening this bug at Ben Finney's request. See https://groups.google.com/forum/?fromgroups#!topic/comp.lang.python/wmDUrpW… for the full thread discussing the problem. Here's a significant excerpt: ------------------------------------------------- The tutorial is misleading on this. It it says plainly: A module can contain executable statements as well as function definitions. […] They are executed only the *first* time the module is imported somewhere. <URL:http://docs.python.org/tutorial/modules.html> but it doesn't make clear that a module can exist in the ‘sys.modules’ list multiple times under different names. ------------------------------------------------- Also note: -------------------------------------------------- The footnote to that is wrong too: > [1] In fact function definitions are also ‘statements’ that are ‘executed’; the execution of a module-level function enters the function name in the module’s global symbol table. I think what it's supposed to say is "... the execution of a module-level def statement ..." --------------------------------------------------- ---------- assignee: docs@python components: Documentation messages: 167628 nosy: docs@python, roysmith priority: normal severity: normal status: open title: Tutorial is unclear on multiple imports of a module. type: enhancement versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15575> _______________________________________

5 5

[issue13510] Clarify that readlines() is not needed to iterate over a file
by Peter Otten 15 Apr '13

15 Apr '13

New submission from Peter Otten <__peter__(a)web.de>: I've been looking at code on the tutor mailing list for some time, and for line in file.readlines(): ... is a common idiom there. I suppose this is because the readlines() method is easily discoverable while the proper way (iterate over the file object directly) is not. A note added to the readlines() documentation might help: """ You don't need the readlines() method to loop over the lines of a file. for line in file: process(line) consumes less memory and is often faster. """ ---------- assignee: docs@python components: Documentation messages: 148679 nosy: docs@python, potten priority: normal severity: normal status: open title: Clarify that readlines() is not needed to iterate over a file type: feature request _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13510> _______________________________________

12 21

[issue13050] RLock support the context manager protocol but this is not documented
by Brian Brazil 14 Apr '13

14 Apr '13

New submission from Brian Brazil <brian.brazil(a)gmail.com>: This is already documented: http://docs.python.org/library/threading.html#using-locks-conditions-and-se… ---------- nosy: +bbrazil _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13050> _______________________________________

6 5

compileall module: exclusion example is path separator-specific
by Paul A. Giannaros 14 Apr '13

14 Apr '13

Hi, The docs for compileall give an example of compiling pyc files in a directory while excluding '.svn' subdirectories: compileall.compile_dir('Lib/', rx=re.compile('/[.]svn'), force=True) Neither this part nor documentation for the 'rx' attribute make clear that the paths searched with the regular expression will have OS specific separators. This example doesn't work on Windows, for example. I think the example should be explicit that the paths will contain the native separators (or it should use pathsep instead of '/', or maybe '[/\\]', to make it clearer in the example). Thanks, Paul

2 1

Bug in the Reference Data Model
by Ted Yin 14 Apr '13

14 Apr '13

It's said that : When it would yield a class method object, it is transformed into a bound user-defined method object whose im_class and im_self attributes are both C. in the Reference <http://docs.python.org/reference/datamodel.html> And I did an EX. >>> class C(object) : ... @classmethod ... def cm(cls) : print cls ... >>> C.cm <bound method type.cm of <class '__main__.C'>> >>> C.cm.im_self <class '__main__.C'> >>> C.cm.im_class <type 'type'> It's not hard for me to understand the result. But unfortunately, in the reference, it's told that im_self should be *the same* as im_class. And in my opinion , 'im_self' shold be C, but im_class is 'type' since C's metaclass is type. So they're obviously *not* 'both C'. -- [This information is automatically generated] *ted.sybil* aka. *ymfoi* aka. *Ted Yin*

2 2

Bug Report: Incorrect Abstract Method Requirements in numbers.Integral Documentation
by Lefavor, Matthew (GSFC-582.0)[MICROTEL LLC] 14 Apr '13

14 Apr '13

To whom it may concern: The documentation for numbers.Integral reports incorrect abstract method requirements for numbers.Integral. The documentation for numbers.Integral (in both Python 2.7 and Python 3.2) states: Subtypes Rational<http://docs.python.org/library/numbers.html#numbers.Rational> and adds a conversion to int<http://docs.python.org/library/functions.html#int>. Provides defaults for float()<http://docs.python.org/library/functions.html#float>, numerator<http://docs.python.org/library/numbers.html#numbers.Rational.numerator>, and denominator<http://docs.python.org/library/numbers.html#numbers.Rational.denominator>, and bit-string operations: <<, >>, &, ^, |, ~. Defaults for operations <<, >>, &, ^, |, and ~ are not provided, and a look at the source code shows that they are all given as abstract methods. In addition, in Python 2.x, numbers.Integral adds an abstract conversion to long. This is not recorded in the documentation. Originally, I was going to report this as a bug, because PEP 3141<http://www.python.org/dev/peps/pep-3141/> (the PEP that specifies the numbers module) goes so far as to include the <<, >>, &, ^, |, and ~ in the source code for numbers.Integral. It looks like somebody already had reported this years ago, however, to python-dev with Issue 3056<http://bugs.python.org/issue3056>. The issue was never resolved, but has since been closed. Since the development community does not seem interested in adding these features, the features should be removed from documentation. Thank you for your time, Matthew Lefavor NASA GSFC [Microtel, LLC] Mail Code 699.0/Org Code 582.0 matthew.lefavor(a)nasa.gov (301) 614-6818 (Desk) (443) 758-4891 (Cell)

2 1

'Bug' in modules tutorial
by Wenceslao Grillo 14 Apr '13

14 Apr '13

Hi, guys, I'm only starting out with Python, and the docs are a great help. Congrats on an excelent work! Found a bug though: in <http://docs.python.org/tutorial/modules.html> there's a footnote that reads: In fact function definitions are also 'statements' that are 'executed'; the execution of a module-level function enters the function name in the module's global symbol table. It seems to me it should be: In fact function definitions are also 'statements' that are 'executed'; the execution of a module-level function *definition* enters the function name in the module's global symbol table. Congrats again! Regards: Wences

2 1

integer leak in refcount docs?
by Daniel Shahaf 14 Apr '13

14 Apr '13

In <http://docs.python.org/c-api/intro.html#reference-count-details>, the example code reads: 1 int 2 set_all(PyObject *target, PyObject *item) 3 { 4 int i, n; 5 6 n = PyObject_Length(target); 7 if (n < 0) 8 return -1; 9 for (i = 0; i < n; i++) { 10 PyObject *index = PyInt_FromLong(i); 11 if (!index) 12 return -1; 13 if (PyObject_SetItem(target, index, item) < 0) 14 return -1; 15 Py_DECREF(index); 16 } 17 return 0; 18 } Seems to me that line 14 leaks a reference to 'index'; that is: @@ -13,2 +13,4 @@ - if (PyObject_SetItem(target, index, item) < 0) + if (PyObject_SetItem(target, index, item) < 0) { + Py_DECREF(index); return -1; + } Does that make sense?

2 1

Python 3 doc update (re) symbolic group: name validity.
by Patrice Joulain 14 Apr '13

14 Apr '13

Hello, I'd like to report a bug dealing with update from Python 2 to Python 3, in the Python 3.x Documentation. Python Standard Library / Chapter 6.2.1 Regular Expression Syntax - says "Group names must be valid Python identifiers" which is not true for 3.x . (?P<name>...) accepts Python 2 valid identifier only (contrary to named fields of collections.namedtuple). I've checked re-HOWTO and tutorial: no specification about valididity of group name, hence no mistake. >>> re.match(r'(?P<DejaVu>test)','test') <_sre.SRE_Match object at 0x00BF25A0> >>> assert 'DéjàVu'.isidentifier() >>> re.match(r'(?P<DéjàVu>test)','test') Traceback (most recent call last): File "C:\Python32\lib\functools.py", line 176, in wrapper result = cache[key] KeyError: (<class 'str'>, '(?P<DéjàVu>test)', 0) During handling of the above exception, another exception occurred: Traceback (most recent call last): File "<stdin>", line 1, in <module> File "C:\Python32\lib\re.py", line 153, in match return _compile(pattern, flags).match(string) File "C:\Python32\lib\re.py", line 255, in _compile return _compile_typed(type(pattern), pattern, flags) File "C:\Python32\lib\functools.py", line 180, in wrapper result = user_function(*args, **kwds) File "C:\Python32\lib\re.py", line 267, in _compile_typed return sre_compile.compile(pattern, flags) File "C:\Python32\lib\sre_compile.py", line 491, in compile p = sre_parse.parse(p, flags) File "C:\Python32\lib\sre_parse.py", line 692, in parse p = _parse_sub(source, pattern, 0) File "C:\Python32\lib\sre_parse.py", line 315, in _parse_sub itemsappend(_parse(source, state)) File "C:\Python32\lib\sre_parse.py", line 552, in _parse raise error("bad character in group name") sre_constants.error: bad character in group name >>> => From Lib\sre_parse.py: def isident(char): return "a" <= char <= "z" or "A" <= char <= "Z" or char == "_" def isdigit(char): return "0" <= char <= "9" def isname(name): # check that group name is a valid stringEnvoyer if not isident(name[0]): return False for char in name[1:]: if not isident(char) and not isdigit(char): return False return True Thank you for dealing this report (Sorry for my bad english). Waiting for some response: <pat.jln(a)hotmail.fr>

2 1

[issue14462] In re's named group the name cannot contain unicode characters
by py.user 14 Apr '13

14 Apr '13

New submission from py.user <port139(a)yandex.ru>: http://docs.python.org/py3k/library/re.html "(?P<name>...) Similar to regular parentheses, but the substring matched by the group is accessible within the rest of the regular expression via the symbolic group name name. Group names must be valid Python identifiers, and each group name must be defined only once within a regular expression." >>> chr(255) 'ÿ' >>> 'ÿ'.isidentifier() True >>> import re >>> re.search(r'(?P<ÿ>a)', 'abc') Traceback (most recent call last): File "/usr/local/lib/python3.2/functools.py", line 176, in wrapper result = cache[key] KeyError: (<class 'str'>, '(?P<ÿ>a)', 0) During handling of the above exception, another exception occurred: Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/local/lib/python3.2/re.py", line 158, in search return _compile(pattern, flags).search(string) File "/usr/local/lib/python3.2/re.py", line 255, in _compile return _compile_typed(type(pattern), pattern, flags) File "/usr/local/lib/python3.2/functools.py", line 180, in wrapper result = user_function(*args, **kwds) File "/usr/local/lib/python3.2/re.py", line 267, in _compile_typed return sre_compile.compile(pattern, flags) File "/usr/local/lib/python3.2/sre_compile.py", line 491, in compile p = sre_parse.parse(p, flags) File "/usr/local/lib/python3.2/sre_parse.py", line 692, in parse p = _parse_sub(source, pattern, 0) File "/usr/local/lib/python3.2/sre_parse.py", line 315, in _parse_sub itemsappend(_parse(source, state)) File "/usr/local/lib/python3.2/sre_parse.py", line 552, in _parse raise error("bad character in group name") sre_constants.error: bad character in group name >>> also: (?P=name) (?(name)yes|no) \g<name> ---------- assignee: docs@python components: Documentation, Regular Expressions messages: 157266 nosy: docs@python, ezio.melotti, mrabarnett, py.user priority: normal severity: normal status: open title: In re's named group the name cannot contain unicode characters type: behavior versions: Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14462> _______________________________________

5 5

[issue13638] PyErr_SetFromErrnoWithFilenameObject is undocumented
by Antoine Pitrou 14 Apr '13

14 Apr '13

New submission from Antoine Pitrou <pitrou(a)free.fr>: Its declaration can be found in Include/pyerrors.h. Same for PyErr_SetExcFromWindowsErrWithFilenameObject. ---------- assignee: docs@python components: Documentation messages: 149877 nosy: arnaudc, docs@python, haypo, pitrou priority: normal severity: normal stage: needs patch status: open title: PyErr_SetFromErrnoWithFilenameObject is undocumented versions: Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13638> _______________________________________

2 1

Apparent bug in python socket howto
by Patrick Maupin 14 Apr '13

14 Apr '13

Thanks for the howto. It's a great conceptual introduction, and I was happy to have it to read when I needed to get my hands a bit dirtier than using SocketServer. But the statement "If we had used s.bind(('', 80)) [the socket would only be] visible within the same machine." appears to be incorrect. As the socket module documentation states, "the empty string represents INADDR_ANY." Thanks and best regards, Patrick Maupin Austin, Texas

2 1

[issue12768] docstrings for the threading module
by Eli Bendersky 13 Apr '13

13 Apr '13

New submission from Eli Bendersky <eliben(a)gmail.com>: The threading module has very few methods with docstrings. Docstrings should be added to all public methods (contents can be borrowed from the documentation). ---------- assignee: docs@python components: Documentation keywords: easy messages: 142247 nosy: docs@python, eli.bendersky priority: low severity: normal stage: needs patch status: open title: docstrings for the threading module type: behavior versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12768> _______________________________________

6 29

[issue8913] Document that datetime.__format__ is datetime.strftime
by Brett Cannon 04 Apr '13

04 Apr '13

New submission from Brett Cannon <brett(a)python.org>: Documenting that would help get people using datetime objects with string.format more. ---------- assignee: docs@python components: Documentation keywords: easy messages: 107179 nosy: brett.cannon, docs@python priority: low severity: normal status: open title: Document that datetime.__format__ is datetime.strftime versions: Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue8913> _______________________________________

12 28

[issue15940] Time module: effect of locale
by Terry J. Reedy 03 Apr '13

03 Apr '13

New submission from Terry J. Reedy: "Module locale Internationalization services. The locale settings can affect the return values for some of the functions in the time module." This is vague and perhaps misleading. The doc also says "Locale information is not used by asctime()." "Locale information is not used by ctime()." Since ctime() = asctime(localtime()), this implies to me that locale is also not used by localtime. Otherwise, locale information would indirectly be used by ctime. (I did not test this directly because I do not know what a legal locale name is on Windows. The doc example 'de_DE' does not work.) Doc also says "time.strftime(format[, t]) %a Locale’s abbreviated weekday name. ... <similar for many other format characters> " So perhaps the doc should say "The locale setting affects the interpretation of many format specifiers in strftime and strptime". If is does anything else, what? ---------- assignee: docs@python components: Documentation messages: 170448 nosy: belopolsky, docs@python, haypo, terry.reedy priority: normal severity: normal stage: needs patch status: open title: Time module: effect of locale versions: Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15940> _______________________________________

3 4

[issue12207] Document ast.PyCF_ONLY_AST
by Éric Araujo 25 Mar '13

25 Mar '13

New submission from Éric Araujo <merwok(a)netwok.org>: Title says it all. ---------- assignee: docs@python components: Documentation files: document-pycf-only-ast.diff keywords: needs review, patch messages: 137203 nosy: docs@python, eric.araujo priority: normal severity: normal stage: patch review status: open title: Document ast.PyCF_ONLY_AST versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file22175/document-pycf-only-ast.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12207> _______________________________________

5 8

[issue16057] Subclasses of JSONEncoder should not be insturcted to call JSONEncoder.decode
by Justin Lebar 18 Mar '13

18 Mar '13

New submission from Justin Lebar: The JSONEncoder documentation says we can implement our own encoder as: >>> class ComplexEncoder(json.JSONEncoder): ... def default(self, obj): ... if isinstance(obj, complex): ... return [obj.real, obj.imag] ... return json.JSONEncoder.default(self, obj) Later on, we give the following example of how to implement the default method in a subclass of json.JSONEncoder: def default(self, o): try: iterable = iter(o) except TypeError: pass else: return list(iterable) return JSONEncoder.default(self, o) These are both incorrect, as a quick reading of the source will reveal. JSONEncoder.default() throws for all input values. We should s/JSONEncoder.default/JSONEncoder.encode/ here, I think. ---------- assignee: docs@python components: Documentation messages: 171363 nosy: Justin.Lebar, docs@python priority: normal severity: normal status: open title: Subclasses of JSONEncoder should not be insturcted to call JSONEncoder.decode versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16057> _______________________________________

6 9

[issue11367] xml.etree.ElementTree.find(all): docs are wrong
by anatoly techtonik 12 Mar '13

12 Mar '13

New submission from anatoly techtonik <techtonik(a)gmail.com>: ElementTree.find(path) docs say: "Finds the first toplevel element with given tag. Same as getroot().find(path). path is the element to look for." That's not true. path can take the form of "//tag" to find any child element with given tag, not strictly top level. ---------- assignee: docs@python components: Documentation messages: 129847 nosy: docs@python, techtonik priority: normal severity: normal status: open title: xml.etree.ElementTree.find(all): docs are wrong versions: Python 2.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue11367> _______________________________________

5 19

[issue14489] repr() function link on the built-in function documentation is incorrect
by H Xu 10 Mar '13

10 Mar '13

New submission from H Xu <xuhdev(a)gmail.com>: The `repr()` built-in function link in this page [ http://docs.python.org/library/functions.html ] should link to the built-in version of `repr()`. It should link to: http://docs.python.org/library/functions.html#repr However, it links to here: http://docs.python.org/library/repr.html#module-repr ---------- assignee: docs@python components: Documentation messages: 157462 nosy: H.Xu, docs@python priority: normal severity: normal status: open title: repr() function link on the built-in function documentation is incorrect versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14489> _______________________________________

6 11

[issue15465] Improved documentation for C API version info
by Nick Coghlan 07 Mar '13

07 Mar '13

New submission from Nick Coghlan <ncoghlan(a)gmail.com>: As far as I can tell, the only mentions of the C API version macros are: 1. In the prose for the stable ABI section (incidentally: this section has a typo in the title) 2. In the documentation for sys.hexversion There should be a clear "API and ABI Versioning" section in the C API docs that covers: PY_LIMITED_API PY_HEX_VERSION PY_MAJOR_VERSION PY_MINOR_VERSION PY_MICRO_VERSION PY_RELEASE_LEVEL PY_RELEASE_SERIAL ---------- assignee: docs@python components: Documentation messages: 166546 nosy: docs@python, ncoghlan priority: normal severity: normal stage: needs patch status: open title: Improved documentation for C API version info type: enhancement _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15465> _______________________________________

3 9

[issue14123] Doc change re old and new string formatting
by Christine Jones 04 Mar '13

04 Mar '13

New submission from Christine Jones <silly.english.knights(a)gmail.com>: Change to this http://docs.python.org/py3k/library/stdtypes.html as suggested by Nick Coghlan here http://www.gossamer-threads.com/lists/python/dev/969817 "The formatting operations described here are modelled on C's printf() syntax. They only support formatting of certain builtin types, and the use of a binary operator means that care may be needed in order to format tuples and dictionaries correctly. As the new string formatting syntax is more powerful, flexible, extensible and handles tuples and dictionaries naturally, it is recommended for new code. However, there are no current plans to deprecate printf-style formatting." ---------- assignee: docs@python components: Documentation messages: 154283 nosy: docs@python, telephonebook priority: normal severity: normal status: open title: Doc change re old and new string formatting _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14123> _______________________________________

8 10

[issue15580] fix True/False/None reST markup
by Chris Jerdonek 08 Feb '13

08 Feb '13

New submission from Chris Jerdonek: The Dev Guide says not to markup True, False, and None in the documentation in a way that generates a link (e.g. ":const:`True`") because "they’re fundamental to the language and should be known to any programmer": http://docs.python.org/devguide/documenting.html#documenting Rather, it says to use "``True``" (and similarly for False and None): This issue is to update the documentation to conform to this guidance. While working on the documentation, I noticed many occurrences of ":const:`True`", for example. See here for some examples, where you can see the hyperlinks: http://docs.python.org/dev/library/tarfile.html#tarfile.TarFile.add ---------- assignee: docs@python components: Documentation messages: 167648 nosy: cjerdonek, docs@python priority: normal severity: normal status: open title: fix True/False/None reST markup _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15580> _______________________________________

5 14

[issue15116] remove out-of-date Mac application scripting documentation
by hhas 02 Feb '13

02 Feb '13

New submission from hhas <hhas(a)users.sourceforge.net>: 1. The entire '4.6. Application Scripting' section should be deleted from the following Python 2 & 3 pages as appscript (and PyOSA) is no longer developed or supported and its use is not recommended for new projects (http://appscript.sourceforge.net/status.html): http://docs.python.org/using/mac.html#application-scripting http://docs.python.org/release/3.2/using/mac.html#application-scripting http://docs.python.org/dev/using/mac.html#application-scripting 2. The sentence 'For more up-to-date implementation of AppleScript support for Python, see the third-party py-appscript project: <http://pypi.python.org/pypi/appscript/>' should be deleted from the following Python 2 page: http://docs.python.org/library/macosa.html ---------- assignee: docs@python components: Documentation messages: 163282 nosy: docs@python, hhas priority: normal severity: normal status: open title: remove out-of-date Mac application scripting documentation versions: Python 2.6, 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/issue15116> _______________________________________

3 4

[issue13048] Handling of paths in first argument of imp.find_module()
by Arfrever Frehtes Taifersar Arahesis 25 Jan '13

25 Jan '13

New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA(a)GMail.Com>: It's undocumented that imp.find_module() supports paths with "/" as the first argument: $ mkdir /tmp/imp_tests $ cd /tmp/imp_tests $ mkdir a $ touch a/b.py $ python3.3 -c 'import imp; print(imp.find_module("a/b"))' (<_io.TextIOWrapper name=4 mode='U' encoding='utf-8'>, 'a/b.py', ('.py', 'U', 1)) ---------- assignee: docs@python components: Documentation, Interpreter Core messages: 144532 nosy: Arfrever, brett.cannon, docs@python, ezio.melotti, ncoghlan priority: normal severity: normal status: open title: Handling of paths in first argument of imp.find_module() versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13048> _______________________________________

2 2

[issue10994] implementation details in sys module
by Maciej Fijalkowski 22 Jan '13

22 Jan '13

New submission from Maciej Fijalkowski <fijall(a)gmail.com>: sys module documentation (as it is online) has some things that in my opinion should be marked as implementation details, but are not. Feel free to counter why not. Some of them has info it should be used for specialized purposes only, but IMO it's not the same as not mandatory for other implementations. Temporary list: _clear_type_cache dllhandle getrefcount getdlopenflags (?) getsizeof - it might be not well defined on other implementations setdlopenflags api_version ---------- assignee: docs@python components: Documentation messages: 126925 nosy: docs@python, fijall priority: normal severity: normal status: open title: implementation details in sys module type: behavior _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10994> _______________________________________

8 17

[issue12103] Documentation of open() does not claim 'e' support in mode string
by Марк Коренберг 03 Jan '13

03 Jan '13

New submission from Марк Коренберг <socketpair(a)gmail.com>: open() and friends (like temporaryfile) does not document 'e' letter in second arguement. At least on Linux, it opens file with O_CLOEXEC. Not sure under Windows. Also, there are other interesting letters (man -a fopen), like: c (since glibc 2.3.3) Do not make the open operation, or subsequent read and write operations, thread cancellation points. e (since glibc 2.7) Open the file with the O_CLOEXEC flag. See open(2) for more information. m (since glibc 2.3) Attempt to access the file using mmap(2), rather than I/O system calls (read(2), write(2)). Currently, use of mmap(2) is only attempted for a file opened for reading. x Open the file exclusively (like the O_EXCL flag of open(2)). If the file already exists, fopen() fails, and sets errno to EEXIST. This flag is ignored for fdopen(). ---------- assignee: docs@python components: Documentation messages: 136223 nosy: docs@python, mmarkk priority: normal severity: normal status: open title: Documentation of open() does not claim 'e' support in mode string _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12103> _______________________________________

4 6

[issue14393] Incorporate Guide to Magic Methods?
by Dirkjan Ochtman 03 Jan '13

03 Jan '13

New submission from Dirkjan Ochtman <dirkjan(a)ochtman.nl>: Should we perhaps ask if we can include https://github.com/RafeKettler/magicmethods in the official docs? It seems nice (and now ranks higher on Google than the official docs...). ---------- assignee: docs@python components: Documentation messages: 156639 nosy: djc, docs@python priority: normal severity: normal status: open title: Incorporate Guide to Magic Methods? _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14393> _______________________________________

6 6

[issue14870] os.utimensat's method description uses wrong notation
by Hynek Schlawack 27 Dec '12

27 Dec '12

New submission from Hynek Schlawack <hs(a)ox.cx>: It says: > os.utimensat(dirfd, path[, atime=(atime_sec, atime_nsec), mtime=(mtime_sec, mtime_nsec), flags=0]) > Updates the timestamps of a file with nanosecond precision. The atime and mtime tuples default to None, which sets those values to the current time. It should be the other way around: atime=None, mtime=None in the signature and explain in the body how they look like. It looks like atime_sec and atime_nsec are some magic constants this way. ---------- assignee: docs@python components: Documentation keywords: easy messages: 161264 nosy: docs@python, eric.araujo, ezio.melotti, georg.brandl, hynek priority: low severity: normal status: open title: os.utimensat's method description uses wrong notation versions: Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14870> _______________________________________

4 4

[issue15990] solidify argument/parameter terminology
by Chris Jerdonek 25 Dec '12

25 Dec '12

New submission from Chris Jerdonek: There is currently some ambiguity in our documentation around positional and keyword arguments (e.g. whether positional means "position-only" or "non-keyword" (roughly) and whether various terms and definitions should be for the calling syntax or the function definition syntax or both). For example, see the python-dev thread starting here: http://mail.python.org/pipermail/python-dev/2012-September/121760.html It would be good to nail down the preferred terminology in a central place. I would suggest that the glossary is a good place to start. For example, when there is a question about what phrase an error message should use or how an error message should be interpreted, it would be good if (at least going forward) the glossary could be used as a definitive resource. This issue may involve making a distinction in our terminology "between arguments (what you pass, call syntax) and parameters (what the function receives, function definition syntax)" (see http://mail.python.org/pipermail/python-dev/2012-September/121771.html ). ---------- assignee: docs@python components: Documentation messages: 170834 nosy: cjerdonek, docs@python priority: normal severity: normal status: open title: solidify argument/parameter terminology _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15990> _______________________________________

8 28

[issue13424] Add examples for open’s new opener argument
by Éric Araujo 22 Nov '12

22 Nov '12

New submission from Éric Araujo <merwok(a)netwok.org>: The new opener argument to open and TextIOWrapper closed two bugs on this tracker: using O_CLOEXEC and replacing the unofficial 'c' mode (O_CREATE). I think it’d be nice to have these as examples (maybe not in the docs of TextIOWrapper which are already huge, but for example in the os docs after the O_* constants). ---------- assignee: docs@python components: Documentation messages: 147840 nosy: docs@python, eric.araujo priority: normal severity: normal status: open title: Add examples for open’s new opener argument versions: Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13424> _______________________________________

6 13

[issue15292] import hook behavior documentation improvement
by Anders Hammarquist 17 Nov '12

17 Nov '12

New submission from Anders Hammarquist <iko(a)iko.pp.se>: When testing Eutaxia on PyPy (1.9) I discovered a discrepancy in the path_hooks import hook implementation. In CPython (2.7), if the find_module() method raises ImportError (as imp.find_module() does when it does not find a module in the given path), will cause the search to continue, whereas PyPy would propagate the ImportError. PyPy has now been changed to behave like CPython. The documentation is not entirely clear, but it does not explicitly document the import hook mechanism as eating an ImportError in find_module(). It should probably be made explicit, which ever way it should be. It is not obvious what is the correct behaviour, given the implicit relative imports, where the ImportError simply means that the import hook cannot find the module. Quick testing on CPython 3.3 indicates that it behaves like PyPy did, but as it doesn't do implicit relative imports my test case didn't work as it was. For 3.3, without implicit relative imports, propagating the ImportError feels like the correct behaviour. The attached demonstration needs a file /tmp/test/foo.py that does a top-level import, e.g. "import errno" to demonstrate the discrepancy. ---------- assignee: docs@python components: Documentation files: testimport.py messages: 164998 nosy: docs@python, iko priority: normal severity: normal status: open title: import hook behavior documentation improvement type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file26315/testimport.py _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15292> _______________________________________

4 6

[issue15677] Gzip/zlib allows for compression level=0
by Sandro Tosi 11 Nov '12

11 Nov '12

New submission from Sandro Tosi: As reported at http://mail.python.org/pipermail/docs/2012-August/009837.html gzip/zlib allows for a compression level=0 (that's basically no compression) so the documentation should mention that possibility too. ---------- assignee: docs@python components: Documentation messages: 168332 nosy: docs@python, sandro.tosi priority: normal severity: normal stage: needs patch status: open title: Gzip/zlib allows for compression level=0 versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15677> _______________________________________

5 4

[issue10358] Doc styles for print should only use dark colors
by Fred L. Drake, Jr. 08 Nov '12

08 Nov '12

New submission from Fred L. Drake, Jr. <fdrake(a)acm.org>: The HTML version of the documentation should include style settings for printing that use fairly dark colors, so that printed copies of pages are more readable. Using a printer that reduces colors to grays causes the light colors in code examples (or inlined references to classes and the like) to nearly drop out, making the result very painful to read. ---------- assignee: docs@python components: Documentation keywords: easy messages: 120741 nosy: docs@python, fdrake priority: normal severity: normal stage: needs patch status: open title: Doc styles for print should only use dark colors type: feature request _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10358> _______________________________________

3 3

[issue16048] Tutorial-classes-remarks: replace paragragh
by Terry J. Reedy 04 Nov '12

04 Nov '12

New submission from Terry J. Reedy: (from python-list thread "data attributes override method attributes?") "9.4. Random Remarks Data attributes override method attributes with the same name; to avoid accidental name conflicts, which may cause hard-to-find bugs in large programs, it is wise to use some kind of convention that minimizes the chance of conflicts. Possible conventions include capitalizing method names, prefixing data attribute names with a small unique string (perhaps just an underscore), or using verbs for methods and nouns for data attributes." The first semi-sentence is wrong. Within a class or instance attribute space, later assignments replace earlier ones. Between them, instance attributes (usually) override class attributes. The exceptions are (some? all?) special methods. One suggestion on the thread is to replace the clause with 'Instance attributes override class attributes', as that is the apparent intent, but the exception needs to be noted. The suggested Method and _data conventions are wrong in that they contradict PEP8 style. Peter Otten suggested that the convention suggestion be shortened to "To avoid name conflicts consider using verbs for methods and nouns for data attributes". ---------- assignee: docs@python components: Documentation messages: 171316 nosy: docs@python, terry.reedy priority: normal severity: normal status: open title: Tutorial-classes-remarks: replace paragragh versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16048> _______________________________________

6 8

[issue15148] shutul.which() docstring could be clearer
by Tshepang Lekhonkhobe 02 Nov '12

02 Nov '12

New submission from Tshepang Lekhonkhobe <tshepang(a)gmail.com>: I find this a little hard to parse (ignoring the obvious typo and the grammar error): """ Given a file, mode, and a path string, return the path whichs conform to the given mode on the path. """ One other suggestion: wouldn't 'file' read better as 'command'? ---------- assignee: docs@python components: Documentation messages: 163515 nosy: docs@python, hynek, tarek, tshepang priority: normal severity: normal status: open title: shutul.which() docstring could be clearer _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15148> _______________________________________

6 13

[issue14893] Tutorial: Add function annotation example to function tutorial
by Zachary Ware 01 Nov '12

01 Nov '12

New submission from Zachary Ware <zachary.ware(a)gmail.com>: A couple months ago, I had never before heard of function annotations and came across a function that had them (I don't remember where or what it was). I spent a fair bit of time searching fruitlessly to figure out what the heck that "->" in the function definition meant. Then finally, a week or two ago, I came across a mention of pep 3107 and function annotations, and figured out what it was that confused me so thoroughly. In an effort to save others from the same confusion, I've put together a small subsection to add to the tutorial about function definition. The text I'm proposing to add is as follows: """ :ref:`Function annotations <function>` are completely optional, arbitrary metadata information about user-defined functions. Python itself currently does not use annotations for anything, so this section is just for familiarity with the syntax. Annotations are stored in the :attr:`__annotations__` attribute of the function as a dictionary and have no effect on any other part of the function. Parameter annotations are defined by a colon after the parameter name, followed by an expression evaluating to the value of the annotation. Return annotations are defined by a literal ``->``, followed by an expression, between the parameter list and the colon denoting the end of the :keyword:`def` statement. The following example has a positional argument, a keyword argument, and the return value annotated with nonsense:: >>> def f(ham: 42, eggs: int = 'spam') -> "Nothing to see here": ... print("Annotations:", f.__annotations__) # print the function's own annotations ... print("Arguments:", ham, eggs) ... >>> f('wonderful') Annotations: {'eggs': <class 'int'>, 'return': 'Nothing to see here', 'ham': 42} Arguments: wonderful spam """ I'd also like to see a link for "->" in the index, either to this note or to the relevant paragraph of compound_stmts.rst or both. The attached patch attempts to add such a link to this section, but I'm not certain that it's done properly. Thanks :) ---------- assignee: docs@python components: Documentation files: annotations_tutorial.patch keywords: patch messages: 161451 nosy: docs@python, zach.ware priority: normal severity: normal status: open title: Tutorial: Add function annotation example to function tutorial type: enhancement versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file25684/annotations_tutorial.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14893> _______________________________________

6 9

[issue14570] Document json "sort_keys" parameter properly
by Nick Coghlan 28 Oct '12

28 Oct '12

New submission from Nick Coghlan <ncoghlan(a)gmail.com>: The json "sort_keys" parameter is actually supported as an argument to dump() and dumps() (and is used that way in the examples), but is only documented as an argument to the JSONEncoder constructor. ---------- assignee: docs@python components: Documentation keywords: easy messages: 158194 nosy: docs@python, ncoghlan priority: normal severity: normal stage: needs patch status: open title: Document json "sort_keys" parameter properly type: enhancement versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14570> _______________________________________

7 16

[issue8996] Add a default role to allow writing bare `len` instead of :func:`len`
by Éric Araujo 27 Oct '12

27 Oct '12

New submission from Éric Araujo <merwok(a)netwok.org>: Following a discussion on IRC: <birkenfeld> I would even prefer having more of just `object` instead of :func:`object` or :class:`object` I think it would be feasible to write a reST role that would use inspect or pydoc to find the type. It would not violate “In the face of ambiguity, refuse the temptation to guess” if it only resolves `somebuiltin` and `some.fully.qualified.name`. Cons: People unfamiliar with reST might confuse ``code`` with `name`; interpreting the role may prove non-trivial (either requiring importing Python module to introspect them, or keeping a mapping of names→types in some file). Thoughts? ---------- assignee: docs@python components: Documentation messages: 107790 nosy: docs@python, merwok priority: normal severity: normal status: open title: Add a default role to allow writing bare `len` instead of :func:`len` type: feature request _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue8996> _______________________________________

5 9

[issue9767] Failures in json doc examples
by Terry J. Reedy 26 Oct '12

26 Oct '12

New submission from Terry J. Reedy <tjreedy(a)udel.edu>: I ran doctest on LibRef 17.2 json saved as .txt. There are 4 failures: 2 are clearly doc issues, the other 2 I do not know. I hope someone reads this who is already familiar DOC PATCHES dumps(2 + 1j, cls=ComplexEncoder) should be json.dumps(2 + 1j, cls=ComplexEncoder) and JSONEncoder().encode({"foo": ["bar", "baz"]}) should be json.JSONEncoder().encode({"foo": ["bar", "baz"]}) Needing similar additions in example code (not caught by doctest) are return JSONEncoder.default(self, o) for chunk in JSONEncoder().iterencode(bigobject): Those fixes leave 2 failures I an unclear about and hope a json expert will comment on. 1.''' Failed example: print(json.dumps({'4': 5, '6': 7}, sort_keys=True, indent=4)) Expected: { "4": 5, "6": 7 } Got: { "4": 5, "6": 7 } ''' The difference is that json puts a trailing space after '5,'. Should it? or should one be added to the doc? 2. ''' Failed example: list(ComplexEncoder().iterencode(2 + 1j)) Expected: ['[', '2.0', ', ', '1.0', ']'] Got: ['[2.0', ', 1.0', ']'] ''' Without knowing how the default iterencode interacts with the overwridden .default() method, I have no idea. ---------- assignee: docs@python components: Documentation, Library (Lib) messages: 115512 nosy: docs@python, terry.reedy priority: normal severity: normal status: open title: Failures in json doc examples type: behavior _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9767> _______________________________________

3 4

[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

[issue13498] os.makedirs exist_ok documentation is incorrect, as is some of the behavior
by R. David Murray 23 Oct '12

23 Oct '12

New submission from R. David Murray <rdmurray(a)bitdance.com>: The documentation for os.makedirs says: If the target directory with the same mode as specified already exists, raises an OSError exception if exist_ok is False, otherwise no exception is raised. This is not correct. If the file exists but the mode is different than that specified (or defaulted) after applying the umask, then an error is raised regardless of the value of exist_ok. The above wording also implies that if the directory exists but has a different mode, that the mode will be changed. Again, this is not what the code does. It's not clear how useful this raise behavior is, but reading the original issue that added this option it is clearly intentional. The documented behavior does seem useful, but if it actually reset the mode that would be a fairly significant behavior change, and would not be a good idea if the user had not specified a mode. However, at the very least exists_ok should not raise if no mode was specified in the call. The error message raised is also wrong in this case, since it says that the error is that the file already exists when we've said that that is OK. A custom error message for this case would be better. ---------- assignee: docs@python components: Documentation, Library (Lib) keywords: easy messages: 148564 nosy: docs@python, r.david.murray priority: normal severity: normal stage: needs patch status: open title: os.makedirs exist_ok documentation is incorrect, as is some of the behavior type: behavior versions: Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13498> _______________________________________

9 22

[issue14394] missing links on performance claims of cdecimal
by Tshepang Lekhonkhobe 21 Oct '12

21 Oct '12

New submission from Tshepang Lekhonkhobe <tshepang(a)gmail.com>: Looking at "What's New" section for cdecimal [1], I see this claim: "Performance gains range from 12x for database applications to 80x for numerically intensive applications..." But there's no link on the benchmark code. [1] http://hg.python.org/cpython/file/9ceac471bd8c/Doc/whatsnew/3.3.rst#l599 ---------- assignee: docs@python components: Documentation messages: 156640 nosy: docs@python, tshepang priority: normal severity: normal status: open title: missing links on performance claims of cdecimal versions: Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14394> _______________________________________

6 8

[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

[issue15936] Add link from os.urandom to random.SystemRandom
by Jacek Bzdak 16 Oct '12

16 Oct '12

New submission from Jacek Bzdak: It would be great if one sentence was added to os.urandom description: "For easy to use interface to system randomness please see random.SystemRandom class". The reason for this change is that many references quote only os.urandom as a cryptographically strong randomeness source in python, and for some people it might be not obvious that there already exists such easy to use api to use cryptographically strong randomness (that is random.SystemRandom class). It would be good to point such people to right class. Myself for example spent last hour trying to create makeshift Random subclass that uses os.urandom as it's randomness source. ---------- assignee: docs@python components: Documentation messages: 170423 nosy: Jacek.Bzdak, docs@python priority: normal severity: normal status: open title: Add link from os.urandom to random.SystemRandom type: enhancement versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15936> _______________________________________

8 10

[issue15586] Provide some examples for usage of ElementTree methods/attributes
by Sarbjit singh 15 Oct '12

15 Oct '12

New submission from Sarbjit singh: Please provide some basic usage examples for ElementTree module documentation. While parsing an xml, most common scenarios will be reading elements from xml, modifying elements, removal of elements. Though there are few examples given for modification of xml element. But if you look from beginners learning point of view, its very hard to just get any idea from the example that is currently provided. There is lot of text there, but what would be more helpful is some small examples for each function so that user can quickly understand its usage there only. I myself is learning Python, but in order to start using this module, i had to search lot of articles on internet on usage of this module. If we could have provided some basic use cases in Python doc itself, user would not have to rely on external sources for learning its usage. Some Basic Scenarios: 1) Parsing an xml and finding some elements of xml 2) deletion of an element from an xml and writing back 3) Modification of an xml element 4) Usage of XPath queries (some basic usage) ---------- assignee: docs@python components: Documentation messages: 167670 nosy: Sarbjit.singh, docs@python, eli.bendersky priority: normal severity: normal status: open title: Provide some examples for usage of ElementTree methods/attributes type: enhancement _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15586> _______________________________________

7 27

[issue12947] Examples in library/doctest.html lack the flags
by Éric Araujo 11 Oct '12

11 Oct '12

New submission from Éric Araujo <merwok(a)netwok.org>: The docs for the doctest module contains examples that use doctest flags to control behavior, but the HTML version does not contain the flags, making the examples useless. I don’t know if this is a bug with the HTML builder or something we can fix in markup. ---------- assignee: docs@python components: Documentation messages: 143775 nosy: docs@python, eric.araujo, georg.brandl priority: normal severity: normal status: open title: Examples in library/doctest.html lack the flags versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12947> _______________________________________

10 35

[issue15922] make howto/urllib2.rst doctests pass
by Chris Jerdonek 09 Oct '12

09 Oct '12

New submission from Chris Jerdonek: This issue is to make the doctests in howto/urllib2.rst pass using vanilla doctest. Patch attached. ---------- assignee: docs@python components: Documentation files: issue-doctest-howto-urllib-1.patch keywords: easy, patch messages: 170305 nosy: cjerdonek, docs@python, orsenthil priority: normal severity: normal status: open title: make howto/urllib2.rst doctests pass versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file27174/issue-doctest-howto-urllib-1.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15922> _______________________________________

4 7

[issue16036] simplify int() signature docs
by Chris Jerdonek 07 Oct '12

07 Oct '12

New submission from Chris Jerdonek: This issue is to simplify the documentation of the built-in function int()'s signature: int([number | string[, base]]) and to make any needed changes to the text of the docs as a consequence. Discussion around this issue began in the comments to issue 14783 about int() and str()'s docstrings. [I copied the nosy list from that issue.] ---------- assignee: docs@python components: Documentation keywords: easy messages: 171238 nosy: chris.jerdonek, cvrebert, docs@python, eric.araujo, ezio.melotti, georg.brandl, rhettinger, storchaka, terry.reedy, tshepang priority: normal severity: normal status: open title: simplify int() signature docs type: enhancement versions: Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16036> _______________________________________

4 15

[issue15888] ipaddress HOWTO examples have some errors
by Chris Jerdonek 07 Oct '12

07 Oct '12

New submission from Chris Jerdonek: The ipaddress HOWTO seems to have some errors in its interactive doctest examples. Below are the errors after running the doctests for it using the regrtest patch posted to issue 15629. (This is the first doc file for which I have used the modified script to open an issue.) The errors seem valid to me on casual inspection. Note that you need to add an initial ">>> import ipaddress" at the beginning of the first doctest example to have these actually run. ---------------------------------------------------------------------- File "Doc/howto/ipaddress.rst", line 146, in ipaddress.rst Failed example: ipaddress.ip_network('2001:db8::1/96') Exception raised: Traceback (most recent call last): File "Lib/doctest.py", line 1287, in __run compileflags, 1), test.globs) File "<doctest ipaddress.rst[15]>", line 1, in <module> ipaddress.ip_network('2001:db8::1/96') File "Lib/ipaddress.py", line 79, in ip_network return IPv6Network(address, strict) File "Lib/ipaddress.py", line 2056, in __init__ raise ValueError('%s has host bits set' % self) ValueError: 2001:db8::1/96 has host bits set ---------------------------------------------------------------------- File "Doc/howto/ipaddress.rst", line 181, in ipaddress.rst Failed example: net4.numhosts Exception raised: Traceback (most recent call last): File "Lib/doctest.py", line 1287, in __run compileflags, 1), test.globs) File "<doctest ipaddress.rst[25]>", line 1, in <module> net4.numhosts AttributeError: 'IPv4Network' object has no attribute 'numhosts' ---------------------------------------------------------------------- File "Doc/howto/ipaddress.rst", line 184, in ipaddress.rst Failed example: net6.numhosts Exception raised: Traceback (most recent call last): File "Lib/doctest.py", line 1287, in __run compileflags, 1), test.globs) File "<doctest ipaddress.rst[27]>", line 1, in <module> net6.numhosts AttributeError: 'IPv6Network' object has no attribute 'numhosts' ---------------------------------------------------------------------- File "Doc/howto/ipaddress.rst", line 190, in ipaddress.rst Failed example: for x in net4.hosts(): Exception raised: Traceback (most recent call last): File "Lib/doctest.py", line 1287, in __run compileflags, 1), test.globs) File "<doctest ipaddress.rst[29]>", line 1 for x in net4.hosts(): ^ SyntaxError: unexpected EOF while parsing ---------------------------------------------------------------------- File "Doc/howto/ipaddress.rst", line 219, in ipaddress.rst Failed example: addr6.exploded Expected: '2001:0db8:0000:0000:0000:0000:0000:0000' Got: '2001:0db8:0000:0000:0000:0000:0000:0001' ---------------------------------------------------------------------- File "Doc/howto/ipaddress.rst", line 221, in ipaddress.rst Failed example: addr6.compressed Expected: '2001:db8::' Got: '2001:db8::1' ---------------------------------------------------------------------- File "Doc/howto/ipaddress.rst", line 244, in ipaddress.rst Failed example: net6[1] Expected: IPv6Address('2001::1') Got: IPv6Address('2001:db8::1') ---------------------------------------------------------------------- File "Doc/howto/ipaddress.rst", line 246, in ipaddress.rst Failed example: net6[-1] Expected: IPv6Address('2001::ffff:ffff') Got: IPv6Address('2001:db8::ffff:ffff') ---------- assignee: docs@python components: Documentation keywords: easy messages: 170097 nosy: cjerdonek, docs@python, ncoghlan, pmoody priority: normal severity: normal stage: needs patch status: open title: ipaddress HOWTO examples have some errors type: behavior versions: Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15888> _______________________________________

4 11

[issue16025] Minor corrections to the zipfile documentation
by Serhiy Storchaka 06 Oct '12

06 Oct '12

New submission from Serhiy Storchaka: The proposed patch corrects a few markup errors in the zipfile documentation and adds a few relevant hyperlinks. ---------- assignee: docs@python components: Documentation files: doc_zipfile-3.3.patch keywords: patch messages: 171157 nosy: docs@python, storchaka priority: normal severity: normal status: open title: Minor corrections to the zipfile documentation versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file27277/doc_zipfile-3.3.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16025> _______________________________________

6 16

[issue11710] Landing pages in docs for standard library packages
by Nick Coghlan 06 Oct '12

06 Oct '12

New submission from Nick Coghlan <ncoghlan(a)gmail.com>: http://docs.python.org/py3k/urllib errors out rather than returning an index page for the modules that are part of the urllib package. This index page could also link to the HOWTO at http://docs.python.org/py3k/howto/urllib2.html The following packages have the same problem: xml, http, xmlrpc, concurrent These ones look OK: logging, curses, html, tkinter These index pages don't necessarily need to be linked from the contents page, but they should exist so that manually typed URLs for these packages do something useful rather than erroring out with a 404. ---------- assignee: docs@python components: Documentation messages: 132481 nosy: docs@python, ncoghlan priority: normal severity: normal status: open title: Landing pages in docs for standard library packages versions: Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue11710> _______________________________________

6 9

Problems with a unittest example and Python 3.3
by Pierazzo Mara 02 Oct '12

02 Oct '12

I tried the very first example I found on the Python documentation at this address: http://docs.python.org/py3k/library/unittest.html#module-unittest import random import unittest class TestSequenceFunctions(unittest.TestCase): def setUp(self): self.seq = list(range(10)) def test_shuffle(self): # make sure the shuffled sequence does not lose any elements random.shuffle(self.seq) self.seq.sort() self.assertEqual(self.seq, list(range(10))) # should raise an exception for an immutable sequence self.assertRaises(TypeError, random.shuffle, (1,2,3)) def test_choice(self): element = random.choice(self.seq) self.assertTrue(element in self.seq) def test_sample(self): with self.assertRaises(ValueError): random.sample(self.seq, 20) for element in random.sample(self.seq, 5): self.assertTrue(element in self.seq) if __name__ == '__main__': unittest.main() On Python 2.7.1 this example used to work, as I was getting back this result: > Ran 3 tests in 0.001s > > OK but when I run this code on Python 3.3 I'm getting this error: Traceback (most recent call last): File "/Users/[USERNAME]/Desktop/prova.py", line 29, in <module> unittest.main() File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/unittest/main.py", line 125, in __init__ self.runTests() File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/unittest/main.py", line 263, in runTests sys.exit(not self.result.wasSuccessful()) SystemExit: False

2 1

Typo in /reference/datamodel.html
by Josh Helzer 02 Oct '12

02 Oct '12

In http://docs.python.org/release/3.2.3/reference/datamodel.html#the-standard-… the description of Bytes sequence type: A bytes object is an immutable array. The items are 8-bit bytes, represented by integers in the range 0 <= x < 256. Bytes literals (like b'abc' and the built-in function bytes() can be used to construct bytes objects. Also, bytes objects can be decoded to strings via the decode() method. Missing closing parenthesis (or rewrite or whatever): A bytes object is an immutable array. The items are 8-bit bytes, represented by integers in the range 0 <= x < 256. Bytes literals (like b'abc'*)* and the built-in function bytes() can be used to construct bytes objects. Also, bytes objects can be decoded to strings via the decode() method. Saw this in 3.2.3, but it also seems to still exist in 3.4.0a0 docs.

2 1

[issue15979] Improve timeit documentation
by Ezio Melotti 02 Oct '12

02 Oct '12

New submission from Ezio Melotti: The documentation of timeit can be improved in several ways: * it should start with a couple of short and comprehensible examples that show the basic usage from the command-line and from the code; * the 3 convenience functions should be moved before the class documentation (and their order inverted); * the methods in the class should be reordered to show the important one first; * more comprehensive (but still comprehensible) examples should be added at the end; * sh syntax highlight should be used for the command-line usage examples; * the note about Python 2.3 can be removed from 3.x docs; http://docs.python.org/dev/library/timeit.html ---------- assignee: docs@python components: Documentation messages: 170785 nosy: docs@python, ezio.melotti priority: normal severity: normal stage: needs patch status: open title: Improve timeit documentation type: enhancement versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15979> _______________________________________

5 9

Re: [docs] simplify int() signature docs (issue 16036)
by pybugs＠rebertia.com 30 Sep '12

30 Sep '12

http://bugs.python.org/review/16036/diff/6079/Doc/library/functions.rst File Doc/library/functions.rst (right): http://bugs.python.org/review/16036/diff/6079/Doc/library/functions.rst#new… Doc/library/functions.rst:636: arguments are given. If *x* is a number, return :meth:`x.__int__() How is "number-ness" determined? Are we just assuming anything with an __int__() method is a number for purposes of explanation? http://bugs.python.org/review/16036/diff/6079/Doc/library/functions.rst#new… Doc/library/functions.rst:648: means to interpret exactly as a code literal, so that the actual base is 2, grammar: "to interpret *x*" or "to interpret the value" or similar. Just "to interpret", without a direct object, sounds a bit odd. "code literal" is unclear. Perhaps replace with "Python integer literal" or "using integer literal syntax"? http://bugs.python.org/review/16036/diff/6079/Doc/library/functions.rst#new… Doc/library/functions.rst:650: ``int('010')`` is, as well as ``int('010', 8)``. Shouldn't we mention somewhere that this raises ValueError and TypeError? http://bugs.python.org/review/16036/

1 0

[issue9650] format codes in time.strptime docstrings
by Chris Rebert 30 Sep '12

30 Sep '12

Chris Rebert added the comment: This is now hardcore nitpicking, but I'm conflicted as to whether %p should be grouped with the other locale-related codes or with %I (since it's hard to imagine using %I or %p in a singleton capacity). In any case, props to Mike for putting an actual patch together. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9650> _______________________________________

1 0

[issue9650] format codes in time.strptime docstrings
by Mike Hoy 30 Sep '12

30 Sep '12

Mike Hoy added the comment: New patch includes time.strptime and the additional changes suggested by Chris Rebert. ---------- Added file: http://bugs.python.org/file27365/issue9650-format-codes_v3.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9650> _______________________________________

1 0

[issue9650] format codes in time.strptime docstrings
by Chris Rebert 30 Sep '12

30 Sep '12

Chris Rebert added the comment: I'm going to bikeshed and again suggest that %I and %p be included for handling 12-hour clock times. Also, the patch seems to only be for strftime(), and not strptime(). ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9650> _______________________________________

1 0

[issue14783] Make int() and str() docstrings correct
by Chris Jerdonek 30 Sep '12

30 Sep '12

Chris Jerdonek added the comment: > So (a) there is precedent for multiple signatures in docstrings For the record, this is also true of 2.7: http://hg.python.org/cpython/file/15fd0b4496e0/Objects/bytearrayobject.c#l2… ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14783> _______________________________________

1 0

[issue9650] format codes in time.strptime docstrings
by Mike Hoy 30 Sep '12

30 Sep '12

Mike Hoy added the comment: Updated patch as per Ezio's comment. ---------- Added file: http://bugs.python.org/file27364/issue9650-format-codes_v2.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9650> _______________________________________

1 0

[issue14783] Make int() and str() docstrings correct
by Chris Jerdonek 30 Sep '12

30 Sep '12

Chris Jerdonek added the comment: The change for issue 15831 contains a number of places where a single signature line was converted to multiple -- but in the docs and not the docstrings. Those instances can also be examined for this issue. The signature line for str() was not updated in that patch, however. ---------- stage: commit review -> needs patch versions: +Python 2.7, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14783> _______________________________________

1 0

[issue9650] format codes in time.strptime docstrings
by Ezio Melotti 30 Sep '12

30 Sep '12

Ezio Melotti added the comment: The patch contains non-ascii apostrophes: s/Locale’s/Locale's/ ---------- nosy: +ezio.melotti _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9650> _______________________________________

1 0

[issue16082] xml.etree.ElementTree.tostringlist does conform to it's documentation
by Ezio Melotti 30 Sep '12

30 Sep '12

Changes by Ezio Melotti <ezio.melotti(a)gmail.com>: ---------- nosy: +ezio.melotti _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16082> _______________________________________

1 0

[issue13801] The Python 3 Docs don't highlight nonlocal
by Georg Brandl 30 Sep '12

30 Sep '12

Georg Brandl added the comment: Pygments is now updated to 1.5pre. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13801> _______________________________________

1 0

[issue14503] docs:Code not highlighted
by Ramchandra Apte 30 Sep '12

30 Sep '12

New submission from Ramchandra Apte <maniandram01(a)gmail.com>: In http://docs.python.org/dev/whatsnew/3.3.html#pep-380-syntax-for-delegating-… , two code samples ---------- assignee: docs@python components: Documentation messages: 157551 nosy: docs@python, ramchandra.apte priority: normal severity: normal status: open title: docs:Code not highlighted _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14503> _______________________________________

7 11

[issue9650] format codes in time.strptime docstrings
by Mike Hoy 30 Sep '12

30 Sep '12

Mike Hoy added the comment: Changed docstring for timemodule.c to include format codes listed here: http://bugs.python.org/msg169193 ---------- keywords: +patch Added file: http://bugs.python.org/file27358/issue9650-format-codes.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9650> _______________________________________

1 0

[issue16090] but is needed somewhere in http://www.python.org/dev/peps/pep-3138/
by Ramchandra Apte 30 Sep '12

30 Sep '12

New submission from Ramchandra Apte: subject I can't remember where the but is needed but I am sure a but is missing somewhere there. ---------- assignee: docs@python components: Documentation messages: 171607 nosy: docs@python, ramchandra.apte priority: normal severity: normal status: open title: but is needed somewhere in http://www.python.org/dev/peps/pep-3138/ versions: Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16090> _______________________________________

3 4

[issue16093] Documentation: links to 3.3
by Stefan Krah 30 Sep '12

30 Sep '12

New submission from Stefan Krah: A couple of links still need to be updated: http://docs.python.org/ Python 3.3 says "in development" and points to 3.4. http://docs.python.org/dev/ Python 3.3 is missing. ---------- assignee: docs@python components: Documentation messages: 171615 nosy: docs@python, skrah priority: normal severity: normal status: open title: Documentation: links to 3.3 type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16093> _______________________________________

2 1

[issue16091] changing sidebar links in http://docs.python.org/
by Ramchandra Apte 30 Sep '12

30 Sep '12

New submission from Ramchandra Apte: In http://docs.python.org/ the "Python 3.3 (in development)" link goes to the Python 3.4 docs. It should be renamed to "Python 3.3". A new link should be added for the Python 3.4 docs and the Python 3.2 link may be removed. ---------- assignee: docs@python components: Documentation messages: 171609 nosy: docs@python, ramchandra.apte priority: normal severity: normal status: open title: changing sidebar links in http://docs.python.org/ _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16091> _______________________________________

2 1

[issue16084] couple of code examples not highlighted in "What's new in Python 3"
by Ramchandra Apte 30 Sep '12

30 Sep '12

New submission from Ramchandra Apte: A couple of code examples are not highlighted in http://docs.python.org/py3k/whatsnew/3.3.html#pep-380-syntax-for-delegating… They should be highlighted with Python highlighting. ---------- assignee: docs@python components: Documentation messages: 171570 nosy: docs@python, ramchandra.apte priority: normal severity: normal status: open title: couple of code examples not highlighted in "What's new in Python 3" versions: Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16084> _______________________________________

3 6

Small typo error in the ip_address module introduction
by Pierre Rouleau 29 Sep '12

29 Sep '12

Hi all, I found the following typo error inside the ip_address module introduction (http://docs.python.org/dev/howto/ipaddress.html). Inside the Host Interfaces section there is the following example: >>> >>> ipaddress.ip_interface('192.0.2.1/24') IPv4Interface('192.0.2.1/24') >>> ipaddress.ip_network('2001:db8::1/96') IPv6Interface('2001:db8::1/96') the second statement should call the ip_interface method instead of the ip_network one. Otherwise, this tutorial is very well written! Thanks! Regards, ... Pierre Rouleau

1 0

[issue9650] format codes in time.strptime docstrings
by Mike Hoy 29 Sep '12

29 Sep '12

Mike Hoy added the comment: >If you like my idea we should discuss it on python-ideas and start a new tracker entry. In the meantime I'd like to create a patch that incorporates Alexander's ideas. If any objections let me know. ---------- nosy: +mikehoy _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9650> _______________________________________

1 0

[issue16077] fix code example in docs for built-in reduce()
by Chris Jerdonek 29 Sep '12

29 Sep '12

New submission from Chris Jerdonek: > Date: Thu, 6 Sep 2012 20:38:21 +0800 > To: docs(a)python.org > Subject: [docs] There is bug about the built-in function reduce in the > document > > I found a bug in the document about reduce : > http://docs.python.org/library/functions.html#reduce > > Here is the patch: > def reduce(function, iterable, initializer=None): > it = iter(iterable) > if initializer is None: > try: > initializer = next(it) > except StopIteration: > raise TypeError('reduce() of empty sequence with no initial > value') > accum_value = initializer > - for x in iterable: > + for x in it: > accum_value = function(accum_value, x) > return accum_value > > It duplicated the first element of iterable > > For example: > In [4]: reduce(lambda x,y:x+y, [1,2,3,4]) > Out[4]: 10 > > In [5]: docreduce.reduce(lambda x,y:x+y ,[1,2,3,4]) > Out[5]: 11 (from: http://mail.python.org/pipermail/docs/2012-September/010513.html and http://mail.python.org/pipermail/docs/2012-September/010526.html ) ---------- assignee: docs@python components: Documentation keywords: easy messages: 171419 nosy: chris.jerdonek, docs@python priority: normal severity: normal stage: needs patch status: open title: fix code example in docs for built-in reduce() type: enhancement versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16077> _______________________________________

3 5

[issue16085] Minor config parser doc change
by Mark Lawrence 29 Sep '12

29 Sep '12

New submission from Mark Lawrence: >From http://docs.python.org/library/configparser.html#examples float = config.getfloat('Section1', 'float') int = config.getint('Section1', 'int') print float + int It's not a good idea to have float or int used like this in examples. Maybe my_float and my_int or sec1_float and sec_int? ---------- assignee: docs@python components: Documentation messages: 171573 nosy: BreamoreBoy, docs@python priority: normal severity: normal status: open title: Minor config parser doc change type: enhancement _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16085> _______________________________________

3 2

Documentation Strings
by Paul Fallon 29 Sep '12

29 Sep '12

For all us who are new to programming, it should be pointed out in the documentation that a double underscore is needed to get the docstring: >>>function_name.__doc__ <--- double underscores Thanks, Paul

2 1

map objects are not lists
by Aaron Leanhardt 29 Sep '12

29 Sep '12

5.1.3. List Comprehensions<http://docs.python.org/dev/tutorial/datastructures.html#list-comprehensions> List comprehensions provide a concise way to create lists. Common applications are to make new lists where each element is the result of some operations applied to each member of another sequence or iterable, or to create a subsequence of those elements that satisfy a certain condition. For example, assume we want to create a list of squares, like: >>> >>> squares = []>>> for x in range(10):... squares.append(x**2)...>>> squares[0, 1, 4, 9, 16, 25, 36, 49, 64, 81] We can obtain the same result with: squares = [x**2 for x in range(10)] This is also equivalent to squares = map(lambda x: x**2, range(10)), but it’s more concise and readable. I think that the last sentence above should read: squares = list(map(lambda x: x**2, range(10))) In other words, the map function returns a map object, not a list object, so the list() function needs to be used to convert it to something that is truly equivalent to the previous definitions of "squares". (In case it matters, I am using Python-3.3.0rc2 on RHEL 6.3.) Aaron -- Aaron E. Leanhardt, http://www.leanhardtingenuities.com/ * --being ingenious is more valuable than being a genius!*

2 1

Problem with the documentation for string.replace
by Dhulipala, Pradyot 29 Sep '12

29 Sep '12

>From http://docs.python.org/library/string.html string.replace(str, old, new[, maxreplace])¶<http://docs.python.org/library/string.html#string.replace> Return a copy of string str with all occurrences of substring old replaced by new. If the optional argument maxreplace is given, the first maxreplace occurrences are replaced. it would appear this needs to be string.replace(old, new[, maxreplace])¶<http://docs.python.org/library/string.html#string.replace> thanks -------------------------------------------------------------------------- NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers. If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing.

2 1

source of python doc site
by CSJ 29 Sep '12

29 Sep '12

Hello doc team, I just know Sphinx yesterday, and http://docs.python.org/py3k/about.html use it to generate html. Is any place I can get source of the files(rst, Makefile, etc) to generate the doc site? Cause I think it is also good example for me to learn using Sphinx. Thanks a lot, Jay

2 1

Re: [docs] docs Digest, Vol 62, Issue 70
by Chris Jerdonek 29 Sep '12

29 Sep '12

> Date: Wed, 12 Sep 2012 15:32:38 -0400 > From: Paul Fallon <paulfallon1106(a)gmail.com> > To: docs(a)python.org > Subject: [docs] Documentation Strings > > For all us who are new to programming, it should be pointed out in the > documentation that a double underscore is needed to get the docstring: >>>>function_name.__doc__ <--- double underscores Hi Paul, Thanks for the suggestion. This is currently mentioned in the tutorial portion of the documentation in the section called "Documentation Strings" though: http://docs.python.org/py3k/tutorial/controlflow.html#documentation-strings It provides a code snippet very similar to the one that you provided. --Chris

2 1

[issue16022] Mistake in "What's New in Python 3.3"
by Ramchandra Apte 29 Sep '12

29 Sep '12

New submission from Ramchandra Apte: In "What's New in Python 3.3", there is a note: Note: Beta users should be aware that this document is currently in draft form. It will be updated substantially as Python 3.3 moves towards release, so it’s worth checking back even after reading earlier versions. If it is still in a draft form, replace "Beta users" with "Pre-release users" or something similar. Else, obviously remove the note. ---------- assignee: docs@python components: Documentation messages: 171150 nosy: docs@python, ramchandra.apte priority: normal severity: normal status: open title: Mistake in "What's New in Python 3.3" _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16022> _______________________________________

4 5

[issue16071] fix link to email.message.Message in mailbox docs
by Chris Jerdonek 29 Sep '12

29 Sep '12

New submission from Chris Jerdonek: > Date: Thu, 13 Sep 2012 00:28:20 -0700 > To: docs(a)python.org > Subject: [docs] Bug in documentation for mailbox module > > I think I may have found a minor bug in the documentation for the > mailbox module, at: > > http://docs.python.org/library/mailbox.html > > Right at the beginning of section 18.4.2. ("Message objects"), when > describing the mailbox.Message class, is the following: > > "A subclass of the email.Message module?s *Message*. Subclasses of > mailbox.Message add mailbox-format-specific state and behavior." > > The word "Message" indicated above with asterisks is a hyperlink to: > > http://docs.python.org/library/mailbox.html#mailbox.Message > > I think it should instead link to: > > http://docs.python.org/library/email.message.html#email.message.Message (from: http://mail.python.org/pipermail/docs/2012-September/010520.html ) ---------- assignee: docs@python components: Documentation keywords: easy messages: 171403 nosy: barry, chris.jerdonek, docs@python, r.david.murray priority: normal severity: normal stage: needs patch status: open title: fix link to email.message.Message in mailbox docs type: enhancement versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16071> _______________________________________

5 9

[issue16053] "strict" parameter is not documented in csv module
by Éric Araujo 28 Sep '12

28 Sep '12

Éric Araujo added the comment: LGTM. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16053> _______________________________________

1 0

[issue16053] "strict" parameter is not documented in csv module
by Kushal Das 28 Sep '12

28 Sep '12

Kushal Das added the comment: Updated with new patch ---------- Added file: http://bugs.python.org/file27341/csv_doc.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16053> _______________________________________

1 0

[issue16053] "strict" parameter is not documented in csv module
by Éric Araujo 28 Sep '12

28 Sep '12

Éric Araujo added the comment: LGTM, except for my previous remark and a missing period after the first line. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16053> _______________________________________

1 0

[issue16053] "strict" parameter is not documented in csv module
by Serhiy Storchaka 28 Sep '12

28 Sep '12

Serhiy Storchaka added the comment: Can native speakers review the patch? ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16053> _______________________________________

1 0

[issue16053] "strict" parameter is not documented in csv module
by Éric Araujo 28 Sep '12

28 Sep '12

Éric Araujo added the comment: Please use ``True`` instead of :const: (this is explained in the doc about the docs in the devguide). ---------- nosy: +eric.araujo _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16053> _______________________________________

1 0

[issue16053] "strict" parameter is not documented in csv module
by Kushal Das 28 Sep '12

28 Sep '12

Kushal Das added the comment: csv.Dialect.strict is now documented. ---------- keywords: +patch nosy: +kushaldas Added file: http://bugs.python.org/file27340/csv_doc.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16053> _______________________________________

1 0

[issue16053] "strict" parameter is not documented in csv module
by Éric Araujo 28 Sep '12

28 Sep '12

Changes by Éric Araujo <merwok(a)netwok.org>: ---------- keywords: +easy stage: -> needs patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16053> _______________________________________

1 0

download problem
by Anthony Petrillo 28 Sep '12

28 Sep '12

Greetings, The download links on http://www.python.org/~gbrandl/build/html/download.html are not working. Would you be able to help me? Anthony

2 2

[issue16069] packaging shows up on docs.python.org/dev
by Chris Jerdonek 28 Sep '12

28 Sep '12

New submission from Chris Jerdonek: Date: Tue, 11 Sep 2012 16:20:54 +0200 To: docs(a)python.org Subject: [docs] packaging documentation should be removed docs.python.org/dev still carries documentation for packaging, despite the package having been removed. http://docs.python.org/dev/library/packaging.html has "3.3.0a4 Documentation" in the footer, so I presume that the page is a leftover. Google returns results which point to the obsolete page, which is misleading. (from http://mail.python.org/pipermail/docs/2012-September/010519.html ) ---------- assignee: docs@python components: Documentation messages: 171400 nosy: chris.jerdonek, docs@python priority: normal severity: normal status: open title: packaging shows up on docs.python.org/dev type: enhancement versions: Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16069> _______________________________________

2 3

Re: [docs] download problem
by Chris Jerdonek 28 Sep '12

28 Sep '12

> Date: Fri, 7 Sep 2012 15:39:52 -0400 > From: Anthony Petrillo <anthony.petrillo(a)gmail.com> > Subject: [docs] download problem > > The download links on > http://www.python.org/~gbrandl/build/html/download.html are not working. > Would you be able to help me? Hi Anthony, does this link for you instead? http://docs.python.org/dev/download.html Also, where did you come across the above URL? Thanks, --Chris

2 1

[issue15821] Improve docs for PyMemoryView_FromBuffer()
by Stefan Krah 28 Sep '12

28 Sep '12

New submission from Stefan Krah: People are using PyMemoryView_FromBuffer() to create and return permanent memoryviews from buffers that are allocated on the stack. See: http://stackoverflow.com/questions/8123121/how-to-get-back-a-valid-object-f… The docs should perhaps warn against this. ---------- assignee: docs@python components: Documentation messages: 169443 nosy: belopolsky, docs@python, ncoghlan, pitrou, skrah priority: normal severity: normal status: open title: Improve docs for PyMemoryView_FromBuffer() type: enhancement versions: Python 3.3, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15821> _______________________________________

3 20

[issue15953] Incorrect some fields declaration in the PyTypeObject documentation
by Serhiy Storchaka 28 Sep '12

28 Sep '12

New submission from Serhiy Storchaka: The declaration of some fields in the PyTypeObject documentation does not match the sources. Here is a patch that fixes the mismatch. ---------- assignee: docs@python components: Documentation files: doc_newtypes.patch keywords: easy, patch messages: 170591 nosy: docs@python, storchaka priority: normal severity: normal status: open title: Incorrect some fields declaration in the PyTypeObject documentation versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file27207/doc_newtypes.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15953> _______________________________________

3 4

[issue16073] fix map() statement in list comprehension example
by Chris Jerdonek 28 Sep '12

28 Sep '12

New submission from Chris Jerdonek: > Date: Thu, 20 Sep 2012 15:14:36 -0400 > To: docs(a)python.org > Subject: [docs] map objects are not lists > > 5.1.3. List Comprehensions<http://docs.python.org/dev/tutorial/datastructures.html#list-comprehensions> > > List comprehensions provide a concise way to create lists. Common > applications are to make new lists where each element is the result of some > operations applied to each member of another sequence or iterable, or to > create a subsequence of those elements that satisfy a certain condition. > > For example, assume we want to create a list of squares, like: >>>> > >>>> squares = []>>> for x in range(10):... squares.append(x**2)...>>> squares[0, 1, 4, 9, 16, 25, 36, 49, 64, 81] > > We can obtain the same result with: > > squares = [x**2 for x in range(10)] > > This is also equivalent to squares = map(lambda x: x**2, range(10)), but > it?s more concise and readable. > > > I think that the last sentence above should read: > > squares = list(map(lambda x: x**2, range(10))) > > In other words, the map function returns a map object, not a list object, > so the list() function needs to be used to convert it to something that is > truly equivalent to the previous definitions of "squares". (In case it > matters, I am using Python-3.3.0rc2 on RHEL 6.3.) (from http://mail.python.org/pipermail/docs/2012-September/010525.html ) ---------- assignee: docs@python components: Documentation keywords: easy messages: 171405 nosy: chris.jerdonek, docs@python priority: normal severity: normal stage: needs patch status: open title: fix map() statement in list comprehension example type: enhancement versions: Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16073> _______________________________________

3 4

[issue15593] urlparse.parse_qs documentation wrong re: urlencode
by Rob Kinyon 28 Sep '12

28 Sep '12

New submission from Rob Kinyon: This may appear to be a duplicate of http://bugs.python.org/issue12390 and http://bugs.python.org/issue833405, but it's not. The documentation of urlparse.parse_qs() should state that in order for urllib.urlencode to properly reverse its output, the doseq parameter must be set to True. Please amend the documentation to make this very clear. Ideally, the documentation of urlencode() would also make it clear that doseq=True is required if the output is from parse_qs(). ---------- assignee: docs@python components: Documentation messages: 167707 nosy: Rob.Kinyon, docs@python priority: normal severity: normal status: open title: urlparse.parse_qs documentation wrong re: urlencode versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15593> _______________________________________

5 4

[issue16072] fix documentation of string.replace() signature
by Chris Jerdonek 28 Sep '12

28 Sep '12

New submission from Chris Jerdonek: > Date: Thu, 13 Sep 2012 09:42:47 -0400 > To: <docs(a)python.org> > Subject: [docs] Problem with the documentation for string.replace > > >From http://docs.python.org/library/string.html > > string.replace(str, old, new[, maxreplace])?<http://docs.python.org/library/string.html#string.replace> > Return a copy of string str with all occurrences of substring old replaced by new. If the optional argument maxreplace is given, the first maxreplace occurrences are replaced. > > it would appear this needs to be > string.replace(old, new[, maxreplace])?<http://docs.python.org/library/string.html#string.replace> (from: http://mail.python.org/pipermail/docs/2012-September/010521.html ) ---------- assignee: docs@python components: Documentation keywords: easy messages: 171404 nosy: chris.jerdonek, docs@python priority: normal severity: normal stage: needs patch status: open title: fix documentation of string.replace() signature type: enhancement versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16072> _______________________________________

2 5

[issue9650] format codes in time.strptime docstrings
by Christian Heimes 28 Sep '12

28 Sep '12

Christian Heimes added the comment: If we want to archive platform independence from the libc's strftime() and strptime() function and its bugs, we could include our own implementation. Or rather than writing our own code we may be able to include some working and well tested code. BSD's libc contains the functions. Its license should allow the inclusion into Python core. http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdtime/ If you like my idea we should discuss it on python-ideas and start a new tracker entry. ---------- nosy: +christian.heimes _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9650> _______________________________________

1 0

[issue16082] xml.etree.ElementTree.tostringlist does conform to it's documentation
by Serhiy Storchaka 28 Sep '12

28 Sep '12

Serhiy Storchaka added the comment: Bug in the documentation, but not in the implementation. See also issue8047 and issue1767933 (changeset 63845:57e631f088d7). ---------- assignee: -> docs@python components: +Documentation nosy: +docs@python, eli.bendersky, storchaka versions: +Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16082> _______________________________________

1 0

Re: [docs] There is bug about the built-in function reduce in the document
by Chris Jerdonek 28 Sep '12

28 Sep '12

> Date: Thu, 6 Sep 2012 20:38:21 +0800 > From: Shafreeck Sea <renenglish(a)gmail.com> > Subject: [docs] There is bug about the built-in function reduce in the > document > > I found a bug in the document about reduce : > http://docs.python.org/library/functions.html#reduce Hi Shafreeck, thanks for the report. I filed an issue in the tracker for this here: http://bugs.python.org/issue16077 --Chris > Here is the patch: > def reduce(function, iterable, initializer=None): > it = iter(iterable) > if initializer is None: > try: > initializer = next(it) > except StopIteration: > raise TypeError('reduce() of empty sequence with no initial > value') > accum_value = initializer > - for x in iterable: > + for x in it: > accum_value = function(accum_value, x) > return accum_value > > It duplicated the first element of iterable > > For example: > In [4]: reduce(lambda x,y:x+y, [1,2,3,4]) > Out[4]: 10 > > In [5]: docreduce.reduce(lambda x,y:x+y ,[1,2,3,4]) > Out[5]: 11

1 0

Re: [docs] map objects are not lists
by Chris Jerdonek 28 Sep '12

28 Sep '12

> Date: Thu, 20 Sep 2012 15:14:36 -0400 > From: Aaron Leanhardt <aaron(a)leanhardtingenuities.com> > Subject: [docs] map objects are not lists > > 5.1.3. List Comprehensions<http://docs.python.org/dev/tutorial/datastructures.html#list-comprehensions> > > ... > > This is also equivalent to squares = map(lambda x: x**2, range(10)), but > it?s more concise and readable. > > > I think that the last sentence above should read: > > squares = list(map(lambda x: x**2, range(10))) Hi Aaron, thanks for the report. I created an issue in the tracker for this here: http://bugs.python.org/issue16073 --Chris

1 0

Re: [docs] unittest documentation mistake?
by Chris Jerdonek 28 Sep '12

28 Sep '12

> Date: Thu, 13 Sep 2012 18:37:13 -0700 > From: John Maxwell <dreamalgebra(a)gmail.com> > Subject: [docs] unittest documentation mistake? > > I believe this is a mistake in the unittest module docs at > http://docs.python.org/library/unittest.html: > > "A test suite is a collection of test cases, test suites, or both. It is > used to aggregate tests that should be executed together." > > Are you sure you don't mean: > > "A test suite is a collection of test cases, fixtures, or both. It is used > to aggregate tests that should be executed together." > > I'm not actually familiar with the module, so feel free to tell me if I got > it wrong. Hi John, the existing documentation is correct if you read the documentation for TestSuite: http://docs.python.org/library/unittest.html#unittest.TestSuite For example, TestSuite.addTest(test) allows you to add TestSuite instances to a TestSuite (which allows nesting). --Chris

1 0

Re: [docs] source of python doc site
by Chris Jerdonek 28 Sep '12

28 Sep '12

> Date: Fri, 14 Sep 2012 11:10:43 +0800 > From: CSJ <changsijay(a)gmail.com> > Subject: [docs] source of python doc site > > Hello doc team, > > I just know Sphinx yesterday, > and http://docs.python.org/py3k/about.html use it to generate html. > > Is any place I can get source of the files(rst, Makefile, etc) to > generate the doc site? Hi Jay, the source for the web site documentation is stored in the Doc/ directory of the source code repository for cpython: http://hg.python.org/cpython/file/e99c0425da59/Doc You can follow the instructions for building the documentation from source here: http://docs.python.org/devguide/documenting.html#building-the-documentation The Dev Guide in general may also help with obtaining the source: http://docs.python.org/devguide/ --Chris

1 0

Re: [docs] Problem with the documentation for string.replace
by Chris Jerdonek 28 Sep '12

28 Sep '12

> Date: Thu, 13 Sep 2012 09:42:47 -0400 > To: <docs(a)python.org> > Subject: [docs] Problem with the documentation for string.replace > > >From http://docs.python.org/library/string.html > > string.replace(str, old, new[, maxreplace])?<http://docs.python.org/library/string.html#string.replace> > Return a copy of string str with all occurrences of substring old replaced by new. If the optional argument maxreplace is given, the first maxreplace occurrences are replaced. > > it would appear this needs to be > string.replace(old, new[, maxreplace])?<http://docs.python.org/library/string.html#string.replace> Hi Pradyot, thanks for the report. I created an issue in the tracker for this here: http://bugs.python.org/issue16072 --Chris

1 0

Re: [docs] Bug in documentation for mailbox module
by Chris Jerdonek 28 Sep '12

28 Sep '12

> Date: Thu, 13 Sep 2012 00:28:20 -0700 > From: Luke Maurits <luke(a)maurits.id.au> > Subject: [docs] Bug in documentation for mailbox module > > I think I may have found a minor bug in the documentation for the > mailbox module, at: > > http://docs.python.org/library/mailbox.html Hi Luke, thanks for the report. I created an issue in the tracker for this here: http://bugs.python.org/issue16071 --Chris

1 0

Re: [docs] packaging documentation should be removed
by Chris Jerdonek 28 Sep '12

28 Sep '12

> Date: Tue, 11 Sep 2012 16:20:54 +0200 > From: Zbigniew J?drzejewski-Szmek <zbyszek(a)in.waw.pl> > Subject: [docs] packaging documentation should be removed > > docs.python.org/dev still carries documentation for packaging, despite the package > having been removed. http://docs.python.org/dev/library/packaging.html has > "3.3.0a4 Documentation" in the footer, so I presume that the page is a leftover. > Google returns results which point to the obsolete page, which is misleading. Hi Zbyszek, thanks for the report. I created an issue in the tracker for this here: http://bugs.python.org/issue16069 --Chris

1 0

suggestion about Python 3.2.3 online documentation about regular expressions
by Winston Chuen-Shih Yang 27 Sep '12

27 Sep '12

See the following page: http://docs.python.org/py3k/library/re.html 6.2.3. Regular Expression Objects regex.search regex.match regex.split : : Suggestion: change "regex" to "pattern". Reason 1: The object is a "Pattern" (_sre.SRE_Pattern). Reason 2: People might confuse "regex" with "re", which is the name of the module. Reason 3: People might think that there is a "regex" class somewhere. (Is there?) Winston

1 0

Re: [docs] simplify int() signature docs (issue 16036)
by ezio.melotti＠gmail.com 27 Sep '12

27 Sep '12

http://bugs.python.org/review/16036/diff/6073/Doc/library/functions.rst File Doc/library/functions.rst (right): http://bugs.python.org/review/16036/diff/6073/Doc/library/functions.rst#new… Doc/library/functions.rst:637: For floating point numbers, this truncates towards zero. On 2012/09/27 11:06:39, storchaka wrote: > I don't know if it worth to mention specifically such details. Floating pointer > numbers truncated first and then __int__() method called for result. This was already there. I think the goal is to say that int() can be used to "extract" the integer part and that e.g. int(3.7) will return 3, without doing any rounding. http://bugs.python.org/review/16036/

1 0

Re: [docs] simplify int() signature docs (issue 16036)
by chris.jerdonek＠gmail.com 27 Sep '12

27 Sep '12

http://bugs.python.org/review/16036/

1 0

Re: [docs] simplify int() signature docs (issue 16036)
by chris.jerdonek＠gmail.com 27 Sep '12

27 Sep '12

Reviewers: storchaka, http://bugs.python.org/review/16036/diff/6073/Doc/library/functions.rst File Doc/library/functions.rst (right): http://bugs.python.org/review/16036/diff/6073/Doc/library/functions.rst#new… Doc/library/functions.rst:637: For floating point numbers, this truncates towards zero. Truncation towards zero seems like useful information to me. It distinguishes the behavior from round() (also in the built-in function docs) and clarifies what happens for negative numbers. Please review this at http://bugs.python.org/review/16036/ Affected files: Doc/library/functions.rst diff --git a/Doc/library/functions.rst b/Doc/library/functions.rst --- a/Doc/library/functions.rst +++ b/Doc/library/functions.rst @@ -629,14 +629,17 @@ to provide elaborate line editing and history features. -.. function:: int([number | string[, base]]) +.. function:: int(x=0) + int(x, base=10) - Convert a number or string to an integer. If no arguments are given, return - ``0``. If a number is given, return ``number.__int__()``. Conversion of - floating point numbers to integers truncates towards zero. A string must be - a base-radix integer literal optionally preceded by '+' or '-' (with no space + Convert a number or string *x* to an integer, or return ``0`` if no arguments + are given. If *x* is a number, return :meth:`x.__int__() <object.__int__>`. + For floating point numbers, this truncates towards zero. + + If *base* is given, then *x* must be a string. The string must be + a base-radix integer literal optionally preceded by ``+`` or ``-`` (with no space in between) and optionally surrounded by whitespace. A base-n literal - consists of the digits 0 to n-1, with 'a' to 'z' (or 'A' to 'Z') having + consists of the digits 0 to n-1, with ``a`` to ``z`` (or ``A`` to ``Z``) having values 10 to 35. The default *base* is 10. The allowed values are 0 and 2-36. Base-2, -8, and -16 literals can be optionally prefixed with ``0b``/``0B``, ``0o``/``0O``, or ``0x``/``0X``, as with integer literals in code. Base 0

1 0

Re: [docs] simplify int() signature docs (issue 16036)
by storchaka＠gmail.com 27 Sep '12

27 Sep '12

http://bugs.python.org/review/16036/diff/6073/Doc/library/functions.rst File Doc/library/functions.rst (right): http://bugs.python.org/review/16036/diff/6073/Doc/library/functions.rst#new… Doc/library/functions.rst:637: For floating point numbers, this truncates towards zero. I don't know if it worth to mention specifically such details. Floating pointer numbers truncated first and then __int__() method called for result. http://bugs.python.org/review/16036/

1 0

simplify int() signature docs (issue 16036)
by storchaka＠gmail.com 27 Sep '12

27 Sep '12

http://bugs.python.org/review/16036/diff/6073/Doc/library/functions.rst File Doc/library/functions.rst (right): http://bugs.python.org/review/16036/diff/6073/Doc/library/functions.rst#new… Doc/library/functions.rst:639: If *base* is given, then *x* must be a string. The string must be Somewhere should be exposed that x must be str, bytes, bytearray or a subclass. http://bugs.python.org/review/16036/

1 0

[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

[issue10669] Document Deprecation Warnings and how to fix
by Ezio Melotti 26 Sep '12

26 Sep '12

Changes by Ezio Melotti <ezio.melotti(a)gmail.com>: ---------- nosy: +chris.jerdonek versions: +Python 3.3, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10669> _______________________________________

1 0

[issue16051] Documentation missing pipes.quote()
by Barry Morrison 26 Sep '12

26 Sep '12

New submission from Barry Morrison: Documentation here: http://docs.python.org/library/pipes.html makes no mention of quote() But the link to Source code: Lib/pipes.py http://hg.python.org/cpython/file/2.7/Lib/pipes.py has: 267 def quote(file): 268 """Return a shell-escaped version of the file string.""" 269 for c in file: 270 if c not in _safechars: 271 break 272 else: 273 if not file: 274 return "''" 275 return file 276 # use single quotes, and put single quotes into double quotes 277 # the string $'b is then quoted as '$'"'"'b' 278 return "'" + file.replace("'", "'\"'\"'") + "'" First _ever_ bug report, apologies if this is incorrect. ---------- assignee: docs@python components: Documentation messages: 171326 nosy: Barry.Morrison, docs@python priority: normal severity: normal status: open title: Documentation missing pipes.quote() type: enhancement versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16051> _______________________________________

2 1

[issue16052] Typo in "What's new in 3.3"
by Lars Buitinck 26 Sep '12

26 Sep '12

New submission from Lars Buitinck: I spotted a minor typo in the "What's new" for Py 3.3, introduced yesterday. See attached patch. ---------- assignee: docs@python components: Documentation files: typo.hg messages: 171333 nosy: docs@python, larsmans priority: normal severity: normal status: open title: Typo in "What's new in 3.3" versions: Python 3.3 Added file: http://bugs.python.org/file27312/typo.hg _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16052> _______________________________________

3 3

[issue16053] "strict" parameter is not documented in csv module
by Serhiy Storchaka 26 Sep '12

26 Sep '12

Changes by Serhiy Storchaka <storchaka(a)gmail.com>: ---------- assignee: -> docs@python components: +Documentation nosy: +docs@python versions: +Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16053> _______________________________________

1 0

[issue14201] Documented caching for shared library's __getattr__ and __getitem__ is incorrect
by Erik Johansson 25 Sep '12

25 Sep '12

Erik Johansson added the comment: The issue14201-v2.patch patch looks good to me at least. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14201> _______________________________________

1 0

[issue15935] clarify argparse docs re: add_argument() type and default arguments
by Chris Jerdonek 25 Sep '12

25 Sep '12

New submission from Chris Jerdonek: This issue is to clarify in the documentation the argparse behavior for which tests were added in issue 15906. The behavior involves when the type callable should be applied to default arguments. See, for example, the following comment for what roughly needs to be added: http://bugs.python.org/issue15906#msg170404 I will provide a patch. ---------- assignee: docs@python components: Documentation keywords: easy messages: 170421 nosy: barry, bethard, cjerdonek, docs@python, r.david.murray priority: normal severity: normal stage: needs patch status: open title: clarify argparse docs re: add_argument() type and default arguments type: behavior versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15935> _______________________________________

5 8

[issue16015] Incorrect startup header in tutorial
by Ramchandra Apte 25 Sep '12

25 Sep '12

New submission from Ramchandra Apte: In http://docs.python.org/py3k/tutorial/interpreter.html#interactive-mode , the header shown is "Python 3.2 (py3k, Sep 12 2007, 12:21:02)". Python 3.2 was no made in Sep 12 2007, so it could not be compiled at that time. It should be a correct date or the date of today. ---------- assignee: docs@python components: Documentation messages: 171126 nosy: docs@python, ramchandra.apte priority: normal severity: normal status: open title: Incorrect startup header in tutorial _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16015> _______________________________________

5 12

[issue14783] Make int() and str() docstrings correct
by Chris Jerdonek 25 Sep '12

25 Sep '12

Chris Jerdonek added the comment: To make it easier to make progress on this docstring issue, I created issue 16036 to focus on int()'s reST documentation. (I have a comment on that aspect.) This will allow the current issue to focus on the docstring aspect. ---------- nosy: +chris.jerdonek _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14783> _______________________________________

1 0

[issue16028] break in finally discards exception
by Mark Dickinson 24 Sep '12

24 Sep '12

Mark Dickinson added the comment: That portion of the documentation has been restored. Closing this issue. ---------- assignee: -> docs@python components: +Documentation nosy: +docs@python resolution: -> fixed status: open -> closed versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16028> _______________________________________

1 0

[issue14167] document return statement in finally blocks
by Yury Selivanov 24 Sep '12

24 Sep '12

New submission from Yury Selivanov <yselivanov(a)gmail.com>: I think that the documentation should put more emphasis on the `return` statement in a `finally` block. Example: def test(): try: 1/0 finally: return 10 >>> test() 10 I think we need to add a warning, or at least a note, that 'return' masks exceptions, if any occurred. ---------- assignee: docs@python components: Documentation messages: 154697 nosy: Yury.Selivanov, docs@python, georg.brandl, rhettinger priority: normal severity: normal status: open title: document return statement in finally blocks type: enhancement versions: Python 2.7, Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14167> _______________________________________

5 17

[issue16020] Missing >>> in Python code example
by Ramchandra Apte 24 Sep '12

24 Sep '12

New submission from Ramchandra Apte: In http://docs.python.org/py3k/tutorial/stdlib2.html#logging , some code in a code sample is missing ">>>". The code is: unsearched = deque([starting_node]) def breadth_first_search(unsearched): node = unsearched.popleft() for m in gen_moves(node): if is_goal(m): return m unsearched.append(m) should be: >>> unsearched = deque([starting_node]) >>> def breadth_first_search(unsearched): >>> node = unsearched.popleft() >>> for m in gen_moves(node): >>> if is_goal(m): >>> return m >>> unsearched.append(m) ---------- assignee: docs@python components: Documentation messages: 171143 nosy: docs@python, ramchandra.apte priority: normal severity: normal status: open title: Missing >>> in Python code example _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16020> _______________________________________

4 5

[issue16019] Python highlighting in tutorial; should be text highlighting
by Ramchandra Apte 24 Sep '12

24 Sep '12

New submission from Ramchandra Apte: In http://docs.python.org/py3k/tutorial/stdlib2.html#logging , a text output has Python highlighting; it should be text highlighting This is incorrectly highlighted text: WARNING:root:Warning:config file server.conf not found ERROR:root:Error occurred CRITICAL:root:Critical error -- shutting down ---------- assignee: docs@python components: Documentation messages: 171142 nosy: docs@python, ramchandra.apte priority: normal severity: normal status: open title: Python highlighting in tutorial;should be text highlighting _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16019> _______________________________________

3 2

[issue16018] Impossible ... line in tutorial
by Ezio Melotti 24 Sep '12

24 Sep '12

Ezio Melotti added the comment: Is it? Python 3.2.3 (default, May 3 2012, 15:54:42) [GCC 4.6.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> # try to access an undefined variable ... n Traceback (most recent call last): File "<stdin>", line 2, in <module> NameError: name 'n' is not defined >>> ---------- nosy: +ezio.melotti resolution: -> invalid stage: -> committed/rejected status: open -> closed type: -> enhancement _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16018> _______________________________________

1 0

[issue16018] Impossible ... line in tutorial
by Ramchandra Apte 24 Sep '12

24 Sep '12

Changes by Ramchandra Apte <maniandram01(a)gmail.com>: ---------- assignee: -> docs@python components: +Documentation nosy: +docs@python _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16018> _______________________________________

1 0

[issue16016] Maybe make one author in ipaddress HOWTO
by Ramchandra Apte 24 Sep '12

24 Sep '12

New submission from Ramchandra Apte: In http://docs.python.org/dev/howto/ipaddress.html, I think there should be one author field with "Peter Moody and Nick Coghlan" on the right side. ---------- assignee: docs@python components: Documentation messages: 171129 nosy: docs@python, ramchandra.apte priority: normal severity: normal status: open title: Maybe make one author in ipaddress HOWTO versions: Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16016> _______________________________________

2 1

[issue16017] "urls" should be capital in tutorial
by Ramchandra Apte 24 Sep '12

24 Sep '12

New submission from Ramchandra Apte: In http://docs.python.org/py3k/tutorial/stdlib.html#internet-access , "from urls" should be "from URLs". ---------- assignee: docs@python components: Documentation messages: 171130 nosy: docs@python, ramchandra.apte priority: normal severity: normal status: open title: "urls" should be capital in tutorial versions: Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16017> _______________________________________

3 2

[issue16014] Incomplete link in docs
by Ramchandra Apte 24 Sep '12

24 Sep '12

New submission from Ramchandra Apte: In http://docs.python.org/py3k/license.html#mersenne-twister, the link http://www.math.keio.ac.jp/ matumoto/MT2002/emt19937ar.html is not complete because there is a space in it. ---------- assignee: docs@python components: Documentation messages: 171125 nosy: docs@python, ramchandra.apte priority: normal severity: normal status: open title: Incomplete link in docs _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16014> _______________________________________

3 2

[issue15964] SyntaxError in asdl when building 2.7 with system Python 3
by Chris Jerdonek 24 Sep '12

24 Sep '12

Chris Jerdonek added the comment: > So can you find out why asdl_c.py actually printed this error? I collected some additional information. Here is the beginning of Parser/asdl_c.py: #! /usr/bin/env python """Generate C code from an ASDL description.""" And in the scenario of this issue I have-- $ python -bash: /opt/local/Library/Frameworks/Python.framework/Versions/Current/bin/python: No such file or directory But-- $ /usr/bin/env python -V Python 3.2.3 Some more data: $ /usr/bin/env python -c "import sys; print(sys.executable)" /opt/local/Library/Frameworks/Python.framework/Versions/3.2/Resources/Python.app/Contents/MacOS/Python $ echo $PATH /opt/local/Library/Frameworks/Python.framework/Versions/Current/bin:/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/usr/local/git/bin:/usr/texbin $ which python /opt/local/bin/python $ /opt/local/bin/python -c "import sys; print(sys.executable)" /opt/local/Library/Frameworks/Python.framework/Versions/3.2/Resources/Python.app/Contents/MacOS/Python It's not immediately clear to me why running `python` doesn't find python in the second $PATH entry even though `which python` does. Also, creating a new terminal doesn't seem to exhibit the same problem, so the error state may not be fully reproducible after all (at least on my machine). In any case, Christian's work-around does resolve the issue for this particular error state while other solutions don't. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15964> _______________________________________

1 0

[issue15964] SyntaxError in asdl when building 2.7 with system Python 3
by Martin v. Löwis 23 Sep '12

23 Sep '12

Martin v. Löwis added the comment: > Just to clarify, in the original scenario, "python" did not refer to > anything. From the original comment: > $ python > No such file or directory So can you find out why asdl_c.py actually printed this error? With no python executable in PATH, it shouldn't even run. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15964> _______________________________________

1 0

[issue15964] SyntaxError in asdl when building 2.7 with system Python 3
by Martin v. Löwis 23 Sep '12

23 Sep '12

Martin v. Löwis added the comment: > Martin meant: > touch Include/Python-ast.h Python/Python-ast.c No, I *actually* meant 'make touch'. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15964> _______________________________________

1 0

[issue15270] "Economy of Expression" section outdated
by Raymond Hettinger 23 Sep '12

23 Sep '12

Raymond Hettinger added the comment: This whole discussion was inane. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15270> _______________________________________

1 0

[issue15270] "Economy of Expression" section outdated
by Roundup Robot 23 Sep '12

23 Sep '12

Roundup Robot added the comment: New changeset 100909b4def0 by Raymond Hettinger in branch 'default': Issue #15270. Appease critics by removing a reference to the docs for super(). http://hg.python.org/devguide/rev/100909b4def0 ---------- nosy: +python-dev _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15270> _______________________________________

1 0

[issue15270] "Economy of Expression" section outdated
by Ezio Melotti 23 Sep '12

23 Sep '12

Ezio Melotti added the comment: IMHO the paragraph about super() can be dropped altogether. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15270> _______________________________________

1 0

[issue15949] docs.python.org not getting updated
by Chris Jerdonek 23 Sep '12

23 Sep '12

New submission from Chris Jerdonek: docs.python.org doesn't seem to be getting updated anymore. For example, this revision from Tuesday, Sept 11 is not reflected: http://hg.python.org/cpython/rev/c8d60d0c736b ---------- assignee: docs@python components: Documentation messages: 170525 nosy: cjerdonek, docs@python priority: normal severity: normal status: open title: docs.python.org not getting updated _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15949> _______________________________________

6 16

[issue15899] howto/unicode.rst doctest corrections
by Chris Jerdonek 23 Sep '12

23 Sep '12

New submission from Chris Jerdonek: This issue is to fix Doc/howto/unicode.rst so that its doctests pass when using the doctest module. Patch forthcoming. ---------- assignee: docs@python components: Documentation keywords: easy messages: 170167 nosy: cjerdonek, docs@python priority: normal severity: normal status: open title: howto/unicode.rst doctest corrections versions: Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15899> _______________________________________

3 10

[issue15964] SyntaxError in asdl when building 2.7 with system Python 3
by Chris Jerdonek 23 Sep '12

23 Sep '12

Changes by Chris Jerdonek <chris.jerdonek(a)gmail.com>: ---------- keywords: +needs review stage: needs patch -> patch review _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15964> _______________________________________

1 0