Mailman 3 August 2012 - docs

[issue15825] Typo in OrderedDict docs
by ThiefMaster Aug. 31, 2012

Aug. 31, 2012

New submission from ThiefMaster: "It is also straight-forward to create an ordered dictionary variant that the remembers the order the keys were last inserted." The first "the" doesn't belong there. ---------- assignee: docs@python components: Documentation messages: 169493 nosy: ThiefMaster, docs@python priority: normal severity: normal status: open title: Typo in OrderedDict docs versions: Python 2.7, Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15825> _______________________________________

4 4

[issue15829] Threading Lock - Wrong Exception Name
by Andrew Svetlov Aug. 31, 2012

Aug. 31, 2012

Andrew Svetlov added the comment: ValueError can be referenced by :exc:`ValueError`. For ThreadError you can add section for describing this exception type like: .. exception:: ThreadError Raised when lock object cannot be acquired or released. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15829> _______________________________________

1 0

[issue15829] Threading Lock - Wrong Exception Name
by Andrew Svetlov Aug. 31, 2012

Aug. 31, 2012

Changes by Andrew Svetlov <andrew.svetlov(a)gmail.com>: ---------- Removed message: http://bugs.python.org/msg169518 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15829> _______________________________________

1 0

[issue15829] Threading Lock - Wrong Exception Name
by Mike Hoy Aug. 31, 2012

Aug. 31, 2012

Mike Hoy added the comment: >>I think RuntimeError should be replaced by ThreadingError for _RLock >>and Condition implementations as well as docs need to be updated. >> >>Also I think this patch should be applied to 3.4 only, it is >>enchacement, not bugfix. >>About fixing docs for 2.7-3.3: I see nothing wrong if current >>inconsistency will be documented, perhaps as *warning* or *note* block. I should warn that ThreadError or `ThreadError` has no link. I've tried to find a place in the docs I could link to but haven't yet. `ValueError` does have a link. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15829> _______________________________________

1 0

[issue15829] Threading Lock - Wrong Exception Name
by Mike Hoy Aug. 31, 2012

Aug. 31, 2012

Mike Hoy added the comment: >>I think RuntimeError should be replaced by ThreadingError for _RLock >>and Condition implementations as well as docs need to be updated. >> >>Also I think this patch should be applied to 3.4 only, it is >>enchacement, not bugfix. >>About fixing docs for 2.7-3.3: I see nothing wrong if current >>inconsistency will be documented, perhaps as *warning* or *note* block. I should warn that ThreadError or `ThreadError` has no link. I've tried to find a place in the docs I could link to but haven't yet. `ValueError` does have a link. ---------- type: enhancement -> _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15829> _______________________________________

1 0

[issue15829] Threading Lock - Wrong Exception Name
by Andrew Svetlov Aug. 31, 2012

Aug. 31, 2012

Andrew Svetlov added the comment: The problem is: threading.Lock raises ThreadingError (which is subclass of RuntimeError for 3.3 but not for 3.2), but threading.Condition raises RuntimeError for the same reason. RLock behavior is even worse: it raises ThreadingError if C accelerator is available in _thread and RuntimeError otherwise. I think RuntimeError should be replaced by ThreadingError for _RLock and Condition implementations as well as docs need to be updated. Also I think this patch should be applied to 3.4 only, it is enchacement, not bugfix. About fixing docs for 2.7-3.3: I see nothing wrong if current inconsistency will be documented, perhaps as *warning* or *note* block. ---------- components: +Library (Lib) nosy: +asvetlov type: -> enhancement _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15829> _______________________________________

1 0

[issue15829] Threading Lock - Wrong Exception Name
by Mike Hoy Aug. 31, 2012

Aug. 31, 2012

Mike Hoy added the comment: Working on a patch now unless there are objections to the OP. ---------- nosy: +docs@python _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15829> _______________________________________

1 0

threading Lock - wrong exception name
by Slawomir Kuszczynski Aug. 30, 2012

Aug. 30, 2012

Hi I found a bug in python docs which can be accessed at links: http://docs.python.org/library/threading.html#lock-objects http://docs.python.org/py3k/library/threading.html#lock-objects Bug is in second paragraph describing threading.Lock. I found that statement: "If an attempt is made to release an unlocked lock, a RuntimeError<http://docs.python.org/library/exceptions.html#exceptions.RuntimeError>will be raised." Which is not true, name of exception is wrong it should be (and it relay is) ThreadError (from threading module) Could someone fix it? -- Br, Slawomir Kuszczynski

1 0

[issue15807] Bogus versionchanged note in logging.handlers.MemoryHandler doc
by Gunnlaugur Thor Briem Aug. 29, 2012

Aug. 29, 2012

New submission from Gunnlaugur Thor Briem: In logging.handlers.MemoryHandler documentation: “Changed in version 2.6: credentials was added.” There's no `credentials` anywhere nearby, and at first glance I can't see anything new in `MemoryHandler` when this was introduced. Presumably the `.. versionchanged::` note just landed there by copy-paste error in 6fb033af9310. ---------- assignee: docs@python components: Documentation messages: 169360 nosy: docs@python, gthb priority: normal severity: normal status: open title: Bogus versionchanged note in logging.handlers.MemoryHandler doc type: enhancement versions: Python 2.6, Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15807> _______________________________________

3 2

multiprocessing documentation of Process.exitcode
by Josh Kupershmidt Aug. 29, 2012

Aug. 29, 2012

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? Josh

1 0