Mailman 3 September 2010 - docs

[issue9583] Document startup option/environment interaction
by Terry J. Reedy Sept. 20, 2010

Sept. 20, 2010

Changes by Terry J. Reedy <tjreedy(a)udel.edu>: ---------- assignee: -> docs@python components: +Documentation -Interpreter Core nosy: +docs@python title: PYTHONOPTIMIZE = 0 is not honored -> Document startup option/environment interaction type: behavior -> _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9583> _______________________________________

1 0

[issue9650] format codes in time.strptime docstrings
by Éric Araujo Sept. 20, 2010

Sept. 20, 2010

Changes by Éric Araujo <merwok(a)netwok.org>: ---------- nosy: +docs@python _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9650> _______________________________________

1 0

[issue1865] Document bytes alias for 2.7
by Terry J. Reedy Sept. 20, 2010

Sept. 20, 2010

Terry J. Reedy <tjreedy(a)udel.edu> added the comment: Changing title to match current issue status. DOC PATCH Grammar section: As near as I can tell, the alternatives for stringprefix ::= "r" | "u" | "ur" | "R" | "U" | "UR" | "Ur" | "uR" should simply be augmented with | "b" | "B" | "br" | "Br" | "bR" | "BR" (on a separate line, indented as indicated). Text section: At the end of the second paragraph, *replace* "The two prefix characters may be combined; in this case, 'u' must appear before 'r'." with "A prefix of 'b' or 'B' is ignored in Python2; it indicates that the literal should become a bytes object in Python 3. A 'u' or 'b' prefix may be followed (but not preceded) by an 'r' prefix." ---------- components: -Interpreter Core resolution: fixed -> title: Bytes alias for 2.6 -> Document bytes alias for 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue1865> _______________________________________

1 0

[issue1865] Bytes alias for 2.6
by Guido van Rossum Sept. 20, 2010

Sept. 20, 2010

Changes by Guido van Rossum <guido(a)python.org>: ---------- nosy: -gvanrossum _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue1865> _______________________________________

1 0

[issue1944] Documentation for PyUnicode_AsString (et al.) missing.
by Mark Lawrence Sept. 20, 2010

Sept. 20, 2010

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/issue1944> _______________________________________

1 0

[issue1865] Bytes alias for 2.6
by Mark Lawrence Sept. 20, 2010

Sept. 20, 2010

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/issue1865> _______________________________________

1 0

[issue1722] Undocumented urllib functions
by Mark Lawrence Sept. 18, 2010

Sept. 18, 2010

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/issue1722> _______________________________________

1 0

[issue1215] Python hang when catching a segfault
by Mark Lawrence Sept. 18, 2010

Sept. 18, 2010

Mark Lawrence <breamoreboy(a)yahoo.co.uk> added the comment: There are several suggestions inline as how how the docs should be changed. ---------- assignee: -> docs@python nosy: +BreamoreBoy, docs@python _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue1215> _______________________________________

1 0

[issue6627] threading.local() does not work with C-created threads
by Nick Coghlan Sept. 18, 2010

Sept. 18, 2010

Nick Coghlan <ncoghlan(a)gmail.com> added the comment: The suggestion in http://bugs.python.org/issue6627#msg116722 is a good one. This a case where the user may legitimately not realise that threading.local is stored in the *temporary* state created by ctypes rather than in something more persistent inside the interpreter. Since the ctypes state is per callback, it won't persist across calls, even when they're made from the same thread. Suggested wording: """Note that if the callback function is called in a new thread that has been created outside of Python's control (i.e., by the foreign code that calls the callback), ctypes creates a new dummy Python thread on every invocation, including recreation of the thread local storage area. While this is correct for most purposes, it does mean that values stored with `threading.local` will *not* survive across different callbacks, even when those calls are made from the same C thread.""" ---------- keywords: +easy resolution: works for me -> stage: committed/rejected -> needs patch status: closed -> open type: behavior -> feature request _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue6627> _______________________________________

1 0

[issue6627] threading.local() does not work with C-created threads
by Nikolaus Rath Sept. 17, 2010

Sept. 17, 2010

Nikolaus Rath <Nikolaus(a)rath.org> added the comment: One point of ctypes is to save the user the trouble of having to create a full blown C extension, so I don't think it's reasonable to expect a ctypes user to have read the full C API documentation as well. Only a very small subset of the page that you gave is actually relevant for use with ctypes. Why not put this information where a ctypes user can find it easily? ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue6627> _______________________________________

1 0