Mailman 3 August 2010 - docs

[issue9037] Add explanation as to how to raise a custom exception in the extending python intermezzo on exceptions
by Jonathan G. Underwood 02 Aug '10

02 Aug '10

New submission from Jonathan G. Underwood <jonathan.underwood(a)gmail.com>: In the documentation section on Extending Python with C or C++ there is an Intermezzo on Errors and Exceptions which shows how to create a custom exception in an extension module. I was just following these instructions for the first time and got to the end and was left wondering how to actually raise the custom exception in my new module, and it wasn't immediately obvious, so I propose to add a brief explanation to the end of that section explaining how. Patch attached. ---------- assignee: docs@python components: Documentation files: extending_how_to_raise_exception.patch keywords: patch messages: 108239 nosy: docs@python, jonathan.underwood priority: normal severity: normal status: open title: Add explanation as to how to raise a custom exception in the extending python intermezzo on exceptions type: feature request versions: Python 2.7 Added file: http://bugs.python.org/file17725/extending_how_to_raise_exception.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9037> _______________________________________

2 1

[issue8562] hasattr(open, 'newlines') example gives incorrect results from PEP0278
by AdamN 02 Aug '10

02 Aug '10

New submission from AdamN <adam(a)varud.com>: This bug from the Ubuntu list is being moved here: https://bugs.launchpad.net/ubuntu/+source/python-defaults/+bug/570737 Newlines support is enabled on Ubuntu but the example from: http://www.python.org/dev/peps/pep-0278/ Does not give the correct results (of True): if hasattr(open, 'newlines'): print 'We have universal newline support' I don't know if this is a documentation problem or whether there is another attr that matters here. ---------- assignee: docs@python components: Documentation, Windows messages: 104454 nosy: adamnelson, docs@python priority: normal severity: normal status: open title: hasattr(open,'newlines') example gives incorrect results from PEP0278 type: behavior versions: Python 2.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue8562> _______________________________________

4 3

[issue9451] Strengthen __*__ system name warning
by Terry J. Reedy 02 Aug '10

02 Aug '10

New submission from Terry J. Reedy <tjreedy(a)udel.edu>: Current" 2.3.2. Reserved classes of identifiers "__*__ System-defined names. These names are defined by the interpreter and its implementation (including the standard library); applications should not expect to define additional names using this convention. The set of names of this class defined by Python may be extended in future versions. See section Special method names." Current pydev thread,Is it intentional that "sys.__debug__ = 1" is illegal in Python 2.7?, Guido said; "But yes, the docs should clarify that *any* use of __*__ names, in any* context, that does not follow explicitly documented use, is subject to breakage without warning." I think I would replace the current "applications ... convention" with Guido's sentence, starting with "*Any* use", though I might put it at the end as the second most important sentence of the paragraph. Until this thread, I did not understand the import of 'expect to' in that middle sentence. Apparently, it means that if a definition works now, it may become invalid in the future if it becomes not just a system word, but a reserved word like __debug__ did. Guido's sentence covers this case and all others, so the current sentence would no longer be needed. ---------- assignee: docs@python components: Documentation messages: 112395 nosy: docs@python, tjreedy priority: normal severity: normal status: open title: Strengthen __*__ system name warning versions: Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9451> _______________________________________

3 4

[issue3849] FUD in documentation for urllib.urlopen()
by Georg Brandl 02 Aug '10

02 Aug '10

Changes by Georg Brandl <georg(a)python.org>: ---------- assignee: georg.brandl -> docs@python nosy: +docs@python _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue3849> _______________________________________

1 0

[issue1581182] Definition of a "character" is wrong
by Éric Araujo 02 Aug '10

02 Aug '10

Changes by Éric Araujo <merwok(a)netwok.org>: ---------- assignee: -> docs@python nosy: +docs@python stage: -> needs patch versions: +Python 2.6, Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue1581182> _______________________________________

1 0

[issue9106] remove numbers from 3-.. level entries in docs toc
by anatoly techtonik 02 Aug '10

02 Aug '10

New submission from anatoly techtonik <techtonik(a)gmail.com>: It seems that left side ToC menu will be more clear without numeric prefixes from chapter on 3-.. nesting levels. How about to remove them? For example - the ToC menu now starting from root level: 15.6. logging — Logging facility for Python * 15.6.1. Logging tutorial o 15.6.1.1. Simple examples o 15.6.1.2. Loggers o 15.6.1.3. Handlers o 15.6.1.4. Formatters o 15.6.1.5. Configuring Logging o 15.6.1.6. Configuring Logging for a Library * 15.6.2. Logging Levels * 15.6.3. Useful Handlers ... will look like: 15.6. logging — Logging facility for Python * 1. Logging tutorial o 1.1. Simple examples o 1.2. Loggers o 1.3. Handlers o 1.4. Formatters o 1.5. Configuring Logging o 1.6. Configuring Logging for a Library * 2. Logging Levels * 3. Useful Handlers ... ---------- assignee: docs@python components: Documentation messages: 108850 nosy: docs@python, techtonik priority: normal severity: normal status: open title: remove numbers from 3-.. level entries in docs toc versions: Python 2.6, Python 2.7, Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9106> _______________________________________

6 12

[issue763043] unable to specify another compiler
by Éric Araujo 02 Aug '10

02 Aug '10

Éric Araujo <merwok(a)netwok.org> added the comment: The bug has been fixed in 2.3, apparently it’s a doc bug now, so reassigning. ---------- assignee: tarek -> docs@python nosy: +docs@python, merwok versions: +Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue763043> _______________________________________

1 0

3.1.2 strings in v2.7 tutorial documentation
by Ercan Altuntaş 01 Aug '10

01 Aug '10

In the section 3.1.2 strings of python tutorial You are giving examples of negative index numbers and at the end there is an view for indexes and the where they correspond as shown at below. The negative index numbers are showing wrong numbers. +---+---+---+---+---+ | H | e | l | p | A | +---+---+---+---+---+ 0 1 2 3 4 5 -5 -4 -3 -2 -1 Best Regards Ercan ALTUNTAS

1 0

[issue8602] documentation of bz2 module mildly erroneous
by Matt Wartell 01 Aug '10

01 Aug '10

New submission from Matt Wartell <matt.wartell+pt(a)gmail.com>: This is related to http://bugs.python.org/issue8601 "bz2.BZ2File should support "with" protocol per PEP 343" The documentation at http://docs.python.org/library/bz2.html states: "This module provides a comprehensive interface for the bz2 compression library. It implements a complete file interface,..." although bz2.BZ2File does not support the __enter__ and __exit__ methods so arguably doesn't implement the "complete file interface". If issue8601 is declined then the documentation should probably note this exception. ---------- assignee: docs@python components: Documentation messages: 104818 nosy: Matt.Wartell, docs@python priority: normal severity: normal status: open title: documentation of bz2 module mildly erroneous type: behavior versions: Python 2.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue8602> _______________________________________

3 5

[issue6696] Profile objects should be documented
by Mark Lawrence 01 Aug '10

01 Aug '10

Changes by Mark Lawrence <breamoreboy(a)yahoo.co.uk>: ---------- assignee: georg.brandl -> docs@python nosy: +docs@python _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue6696> _______________________________________

1 0