Mailman 3 January 2011 - docs

[issue9717] operator module - "in place" operators documentation
by Arnaud Delobelle 08 Jan '11

08 Jan '11

New submission from Arnaud Delobelle <arnodel(a)googlemail.com>: More detailed explanation of how in place operators work, and how they are related to the operator module iadd, isub, ... functions. Submitted following this message on python-list: http://mail.python.org/pipermail/python-list/2010-August/1254243.html ---------- assignee: docs@python components: Documentation files: operator_inplace.diff keywords: patch messages: 115237 nosy: arno, docs@python priority: normal severity: normal status: open title: operator module - "in place" operators documentation versions: Python 3.3 Added file: http://bugs.python.org/file18682/operator_inplace.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9717> _______________________________________

3 6

[issue10533] Need example of using __missing__
by Raymond Hettinger 08 Jan '11

08 Jan '11

Raymond Hettinger <rhettinger(a)users.sourceforge.net> added the comment: See r87858. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10533> _______________________________________

1 0

[issue10813] Suppress adding decimal point for places=0 in moneyfmt()
by Carsten Grohmann 08 Jan '11

08 Jan '11

New submission from Carsten Grohmann <carstengrohmann(a)gmx.de>: Hi, the documentation of the decimal module contains a small recipe called moneyfmt() for format decimal values. It's very usefull. I'd like to suggest a small improvement because the output is incorrect with given dp="." (default) and places=0. Example: >>> moneyfmt(decimal.Decimal('-0.02'), neg='<', trailneg='>', places=1) '<0.0>' >>> moneyfmt(decimal.Decimal('-0.02'), neg='<', trailneg='>', places=0) '<0.>' Change: --- moneyfmt.py 2011-01-03 13:56:32.774169788 +0100 +++ moneyfmt.py.new 2011-01-03 13:56:58.130165330 +0100 @@ -33,7 +33,8 @@ build(trailneg) for i in range(places): build(next() if digits else '0') - build(dp) + if places: + build(dp) if not digits: build('0') i = 0 What do you think about the change? Regrads, Carsten ---------- assignee: docs@python components: Documentation messages: 125164 nosy: cgrohmann, docs@python priority: normal severity: normal status: open title: Suppress adding decimal point for places=0 in moneyfmt() _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10813> _______________________________________

2 5

[issue10856] documentation for ImportError parameters and attributes
by anatoly techtonik 07 Jan '11

07 Jan '11

New submission from anatoly techtonik <techtonik(a)gmail.com>: Need documentation for ImportError parameters and exception instance attributes. ---------- assignee: docs@python components: Documentation messages: 125655 nosy: docs@python, techtonik priority: normal severity: normal status: open title: documentation for ImportError parameters and attributes type: feature request versions: Python 2.7, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10856> _______________________________________

3 4

[issue10846] typo in threading doc's: "size of the resource size"
by Vladimir Rutsky 06 Jan '11

06 Jan '11

New submission from Vladimir Rutsky <altsysrq(a)gmail.com>: I think there is a typo in threading documentation: > In any situation where the size of the resource size is fixed, > you should use a bounded semaphore. - "size of the resource size", see attached patch for proposed fix. (Based on official http://svn.python.org/projects/python/branches/py3k/ repository.) ---------- assignee: docs@python components: Documentation files: threading_typo_size_of_size.patch keywords: patch messages: 125580 nosy: docs@python, rutsky priority: normal severity: normal status: open title: typo in threading doc's: "size of the resource size" versions: Python 3.3 Added file: http://bugs.python.org/file20293/threading_typo_size_of_size.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10846> _______________________________________

2 1

[issue6269] threading documentation makes no mention of the GIL
by Antoine Pitrou 06 Jan '11

06 Jan '11

Antoine Pitrou <pitrou(a)free.fr> added the comment: Ok, done in r87792, r87793 and r87794, thank you. ---------- nosy: +pitrou resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue6269> _______________________________________

1 0

[issue10840] pyarg_parsetuple docs and py_buffer
by Antoine Pitrou 05 Jan '11

05 Jan '11

New submission from Antoine Pitrou <pitrou(a)free.fr>: The docs for "s*" and friends should mention that contiguity of the buffer is automatically enforced. ---------- assignee: docs@python components: Documentation messages: 125488 nosy: docs@python, exarkun, mark.dickinson, pitrou priority: normal severity: normal stage: needs patch status: open title: pyarg_parsetuple docs and py_buffer versions: Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10840> _______________________________________

2 5

[issue10001] ~Py_buffer.obj field is undocumented, though not hidden
by Nick Coghlan 04 Jan '11

04 Jan '11

Nick Coghlan <ncoghlan(a)gmail.com> added the comment: Closing as a dupe of 10181, but transferring Lenard's comments over there. ---------- resolution: -> duplicate status: open -> closed superseder: -> Problems with Py_buffer management in memoryobject.c (and elsewhere?) _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10001> _______________________________________

1 0

[issue10001] ~Py_buffer.obj field is undocumented, though not hidden
by Antoine Pitrou 03 Jan '11

03 Jan '11

Changes by Antoine Pitrou <pitrou(a)free.fr>: ---------- nosy: +mark.dickinson, ncoghlan _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10001> _______________________________________

1 0

[issue10809] complex() comments wrongly say it supports NaN and inf
by Andrew Dalke 03 Jan '11

03 Jan '11

New submission from Andrew Dalke <dalke(a)dalkescientific.com>: complex("nan") raises "ValueError: complex() arg is a malformed string" while complex(float("nan")) returns (nan+0j). This was reported in http://bugs.python.org/issue2121 with the conclusion "wont fix". complex("inf") has the same behaviors. The implementation in complexobject.c says /* a valid complex string usually takes one of the three forms: <float> - real part only <float>j - imaginary part only <float><signed-float>j - real and imaginary parts where <float> represents any numeric string that's accepted by the float constructor (including 'nan', 'inf', 'infinity', etc.), and <signed-float> is any string of the form <float> whose first character is '+' or '-'. This comment is wrong and it distracted me for a while as I tried to figure out why complex("nan") wasn't working. It should be fixed, with the word "including" replaced by "excluding". I don't have a real need for complex("nan") support - this was of intellectual interest only. Also of intellectual interest, PyPy 1.4 does accept complex("nan") but converts complex("nan+nanj") to (nannanj), so it suffers from the strange corner cases which Raymond points out when advocating for "wont fix." Because ---------- assignee: docs@python components: Documentation messages: 125104 nosy: dalke, docs@python priority: normal severity: normal status: open title: complex() comments wrongly say it supports NaN and inf versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10809> _______________________________________

2 2