Mailman 3 September 2010 - docs

[issue6627] threading.local() does not work with C-created threads
by Amaury Forgeot d'Arc Sept. 17, 2010

Sept. 17, 2010

Amaury Forgeot d'Arc <amauryfa(a)gmail.com> added the comment: This is not specific to ctypes. Please read http://docs.python.org/c-api/init.html#thread-state-and-the-global-interpre… specially the paragraph that says "...when threads are created from C...". Is it explicit enough? How would you change it? ---------- _______________________________________ 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: To be a bit more constructive, why not add something like this in paragraph to http://docs.python.org/library/ctypes.html#callback-functions: "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. That means that values stored with `threading.local` will *not* survive across different callbacks. ---------- _______________________________________ 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: No, I am not saying that the behaviour of ctypes is wrong. It just happens to have some effects on threading.local that I think should be documented. That's why I reassigned this as a documentation bug. Please reconsider closing this bug. I'm also happy to change the type to "Feature request". As an aside: I think in most cases one uses ctypes to call functions that are already compiled, so changing the source is not an option. ---------- _______________________________________ 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 Amaury Forgeot d'Arc Sept. 17, 2010

Sept. 17, 2010

Amaury Forgeot d'Arc <amauryfa(a)gmail.com> added the comment: > ctypes performs the initializations in a way that break the > threading.local functionality. Not quite. ctypes (or more exactly: the PyGILState_Ensure() and PyGILState_Release() functions, which are the standard API to do this) is in a situation where it must call Python code from a thread which has no PyThreadState. So it creates a thread state, runs the code, and destroys the thread state; is this wrong? If you want to keep Python state during your C thread, there are 4 lines to add to your function: void *async_cb(void *dummy) { PyGILState_STATE gstate = PyGILState_Ensure(); Py_BEGIN_ALLOW_THREADS (*callback_fn)(); (*callback_fn)(); Py_END_ALLOW_THREADS PyGILState_Release(gstate); pthread_exit(NULL); } ---------- resolution: -> works for me status: open -> closed _______________________________________ 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

Changes by Nikolaus Rath <Nikolaus(a)rath.org>: ---------- resolution: invalid -> _______________________________________ 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: @Swapnil: the rules you quote are correct for the C extension, but do not apply when using ctypes, because ctypes is doing the required initializations automatically. However, if Amaury is correct, ctypes performs the initializations in a way that break the threading.local functionality. I think the best way to address this bug would therefore be to add a warning to the ctypes documentation that C created threads will not support threading.local(). ---------- assignee: -> docs@python components: +Documentation -Library (Lib) nosy: +docs@python status: closed -> open _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue6627> _______________________________________

1 0

[issue1753718] base64 "legacy" functions violate RFC 3548
by Mark Lawrence Sept. 17, 2010

Sept. 17, 2010

Changes by Mark Lawrence <breamoreboy(a)yahoo.co.uk>: ---------- assignee: barry -> docs@python nosy: +docs@python versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue1753718> _______________________________________

1 0

Add % "string formatting" description to precedence table
by Bob Holmberg Sept. 17, 2010

Sept. 17, 2010

Hello, I am unsure of the precedence of the '%' operator when used as the string formatting operator. I rely on the precedence chart/table in section 5.15 on page http://docs.python.org/reference/expressions.html . I must assume that the precedence of '%', described as "remainder" in the Description column also holds for that operator's use for string formatting. It would be a great help if "string formatting" were added to the description column to make this use of the '%' operator clear and explicit. Thanks, Bob Holmberg

1 0

[issue1705393] Select() failure (race condition)
by Mark Lawrence Sept. 17, 2010

Sept. 17, 2010

Mark Lawrence <breamoreboy(a)yahoo.co.uk> added the comment: I've changed things in reply to msg85311, feel free to alter things again if you disagree. ---------- assignee: -> docs@python components: +Documentation -Extension Modules, Library (Lib) nosy: +BreamoreBoy, docs@python versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6, Python 3.0 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue1705393> _______________________________________

1 0

[issue1665333] Documentation missing for OptionGroup class in optparse
by Éric Araujo Sept. 16, 2010

Sept. 16, 2010

Éric Araujo <merwok(a)netwok.org> added the comment: Adding docs@ to nosy. amk: Please reassign to docs@ if you don’t intend to work on this. ---------- nosy: +docs@python, eric.araujo versions: +Python 3.1, Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue1665333> _______________________________________

1 0