On Fri, Mar 30, 2012 at 2:01 AM, andrew.svetlov
> +- Issue #14409: IDLE doesn't not execute commands from shell,
> + error with default keybinding for Return. (Patch by Roger Serwy)
The double negative here makes this impossible to understand. Could we
please get an updated NEWS entry that explains what actually changed
in IDLE to fix this?
Perhaps something like "IDLE now always sets the default keybind for
Return correctly, ensuring commands can be executed in the IDLE shell
window"? (assuming that's what happened).
This is important, folks: NEWS entries need to be comprehensible for
people that *haven't* read the associated tracker issue. This means
that issue titles (which generally describe a problem someone was
having) are often inappropriate as NEWS items. NEWS items should be
short descriptions that clearly describe *what changed*, perhaps with
some additional information to explain a bit about why the change was
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
bugs.python.org is down so I'm reporting the bug here :-)
We have a crash in our product when tracing is enabled by
sys.settrace() and threading.settrace(). If a Python generator is
created in a C thread, calling the generator later in another thread
may crash if Python tracing is enabled.
- the C thread calls PyGILState_Ensure() which creates a temporary
Python thread state
- a generator is created, the generator has a reference to a Python
frame which keeps a reference to the temporary Python thread state
- the C thread calls PyGILState_Releases() which destroys the
temporary Python thread state
- when the generator is called later in another thread, call_trace()
reads the Python thread state from the generator frame, which is the
destroyed frame => it does crash on a pointer dereference if the
memory was reallocated (by malloc()) and the data were erased
To reproduce the crash, unpack the attached
generator_frame_bug.tar.gz, compile the C module using "python
setup.py build" and then run "PYTHONPATH=$(ls -d build/lib*/) python
test.py" (or just "python test.py if you installed the _test module).
You may need to use Valgrind to see the error, or call memset(tstate,
0xFF, sizeof(*tstate)) before free(tstate) in tstate_delete_common().
Calling the generator should update its reference to the Python state
thread in its frame. The generator may also clears frame->f_tstate (to
detect bugs earlier), as it does for frame->f_back (to avoid a
reference cycle). Attached patch implements this fix for Python 3.3.
On Fri, 30 Mar 2012 04:21:22 +0200
victor.stinner <python-checkins(a)python.org> wrote:
> diff --git a/pep-0418.txt b/pep-0418.txt
> --- a/pep-0418.txt
> +++ b/pep-0418.txt
> @@ -190,13 +190,13 @@
> Name Resolution Adjusted by NTP? Action on suspend
> ========================= =============== ================ =================
Is it supposed to be resolution or accuracy?
For example for QueryPerformanceCounter() and timeGetTime(), you are
giving an accuracy, but for CLOCK_* you are giving a resolution.
After talking with Martin and several others during the language
summit and elsewhere around PyCon, PEP 397 should be accepted. I don't
remember who, but some suggested it should just be a regular old
feature instead of going through the PEP process. So...does this even
need to continue the PEP process?
Vinay - is the code you have on bitbucket ready to roll into CPython,
thus into the installer?
On Fri, Mar 30, 2012 at 2:12 PM, <martin(a)v.loewis.de> wrote:
> Zitat von Nick Coghlan <ncoghlan(a)gmail.com>:
>> On Fri, Mar 30, 2012 at 2:01 AM, andrew.svetlov
>> <python-checkins(a)python.org> wrote:
>>> +- Issue #14409: IDLE doesn't not execute commands from shell,
>>> + error with default keybinding for Return. (Patch by Roger Serwy)
>> The double negative here makes this impossible to understand. Could we
>> please get an updated NEWS entry that explains what actually changed
>> in IDLE to fix this?
> Please consider that Andrew is not a native speaker of English. So
> it's unfair to ask him to rewrite the NEWS entry. That can only
> be done by a native speaker.
The NEWS entries need to be treated as being at least close to on par
with the rest of the docs - it's OK if someone can't come up with the
words themselves, but if that's the case, then it's preferable to ask
for help with the wording explicitly.
Is my suggested rephrasing correct? I don't know, as I'm not familiar
with either the original problem or what was done to fix it.
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
I see this was reported as a debian bug.
We encountered it as well.
To reproduce, using virtualenv 1.7+ on Python 2.7.2 on Ubuntu, create a
virtualenv. Move that virtualenv to a host with Python 2.7.3RC2 yields:
jaraco@vdm-dev:~$ /usr/bin/python2.7 -V
jaraco@vdm-dev:~$ env/bin/python -V
jaraco@vdm-dev:~$ env/bin/python -c "import os; os.urandom()"
Traceback (most recent call last):
File "<string>", line 1, in <module>
AttributeError: 'module' object has no attribute 'urandom'
This bug causes Django to not start properly (under some circumstances).
I reviewed the changes between v2.7.2 and 2.7 (tip) and it seems there was
substantial refactoring of the os and posix modules for urandom.
I still don't fully understand why the urandom method is missing (because
the env includes the python 2.7.2 executable and stdlib).
I suspect this change is going to cause some significant backward
compatibility issues. Is there a recommended workaround? Should I file a
Sorry if this is the wrong place to discuss this potential bug - feel free to point me in the right direction if so.
I'm running OS X 10.7.3, and have two python2.7s installed, one system default in /usr/bin and the other by homebrew symlinked in /usr/local/bin.
While running a configure script, distutils.sysconfig.get_config_var is not returing a full path for my homebrew Python framework, like so:
Python 2.7.2 (default, Mar 28 2012, 02:31:16)
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)] on darwin
'-u _PyMac_Error Python.framework/Versions/2.7/Python'
(the full path should be /usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/Python)
Whereas from the system python in /usr/bin:
Python 2.7.1 (r271:86832, Jul 31 2011, 19:30:53)
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin
'-u _PyMac_Error /System/Library/Frameworks/Python.framework/Versions/2.7/Python'
This seems like a bug, no?
Thanks for the help,
Upfront hosting (Izak Burger) is going to do a Debian upgrade of the bug
tracker machine "soon" (likely tomorrow). This may cause some outage,
since there is a lot of custom stuff on the machine which may
break with newer (Python) versions. I'll notify here when the upgrade