Stephan R.A. Deibel added the comment:
I think I misunderstood the implementation of EnterNonRecursiveMutex -- the
mutex that could block there is the internal 'cs' mutex, which would only be
held only briefly while Enter/LeaveNonRecursiveMutex are running, and it looks
like the &#x
New submission from Stephan R.A. Deibel:
In acquire_timed in _threadmodule.c (used to implement threading lock
acquire()) there is an optimization from
https://github.com/python/cpython/commit/e75ff35af2b6c85d48c68b95f295aeac7396b162
that says it first tries non-blocking lock w/o releasing
Stephan R.A. Deibel added the comment:
OK, sounds reasonable to me.
--
___
Python tracker
<http://bugs.python.org/issue20609>
___
___
Python-bugs-list mailin
Stephan R.A. Deibel added the comment:
Yes, thanks, that patch fixes it so it builds successfully. Tried w/ Python
3.4rc1 on Windows 7 w/ VS2010.
Of course maybe it should really be building kill_python.exe for the matching
architecture and running that, but I'm not sure how to do tha
Stephan R.A. Deibel added the comment:
There's no patch attached... or am I just confused?
--
___
Python tracker
<http://bugs.python.org/issue20609>
___
___
New submission from Stephan R.A. Deibel:
The changes made in Issue19788 break the ability to build x64 build target on a
32-bit Windows machine because PreBuildEvent entries in pythoncore.vcxproj end
up trying to run the 64-bit kill_python.exe, causing critical build steps to
fail. Removing
Stephan R.A. Deibel added the comment:
Here's a patch to the docs that notes the issue and refers the reader to the
relevant execution model docs page. I have also attempted to clarify the
"interaction with dynamic features" section of the execution model page.
--
k
Stephan R.A. Deibel added the comment:
Ah, thanks, there it is... I thought this must be dealt with somewhere but
couldn't find it. Maybe should add something to the 'exec' statement docs
http://docs.python.org/py3k/library/functions.html#exec to reference this (from
a us
New submission from Stephan R.A. Deibel :
Calling exec() on code that includes a list comprehension that references a
defined local variable x fails incorrectly on "NameError: global name 'x' not
defined".
--
files: execlistcomp.py
messages: 149050
nosy: sdei
Stephan R.A. Deibel added the comment:
Sorry, the print statement in the file needs a tweak to work with Python 3.2,
but the bug does occur there also.
--
___
Python tracker
<http://bugs.python.org/issue13
New submission from Stephan R.A. Deibel :
The tracer set with sys.settrace() is called incorrectly with a 'line' event on
a 'pass' that is at the end of an 'else' clause on the final line of a function
even if the else block is not executed by the interpreter.
Stephan R.A. Deibel added the comment:
He he, well my attempts at replicating this on Linux and OS X failed
using Python 2.3->2.6 so I'm closing this bug. I'm uploading the test
case for what it's worth. My best guess at what happened is that there
was some interaction w/
Stephan R.A. Deibel added the comment:
Here is a patch against Python 2.6.1 that restores errno after the
"sanity check" in lock_PyThread_release_lock in Modules/threadmodule.c.
A potential controversy is whether it should be done here or in
thread_pthread.h but I believe that
Stephan R.A. Deibel added the comment:
It appears to be specific to 2.x and does not occur under Python 3.0:
Python 3.0 (r30:67503, Jan 15 2009, 09:27:16)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license&qu
Stephan R.A. Deibel added the comment:
If you are at PyCon 2009 sprints, try to see if you can find John
Ehresman in the Python Core sprint to see it happen at line 115 of
threadops.c in the Wing 3.2 source base. If you're not there or can't
find him, I'll try to make a smal
Stephan R.A. Deibel added the comment:
I should have noted that adding co_firstlineno as well to the hash would
be necessary to distinguish like code objects within the same file. The
example has them on the same lines in different files but changing the
first line of the defs doesn't m
New submission from Stephan R.A. Deibel:
The algorithm in code_hash() in codeobject.c can return the same hash
value for different code objects.
Presumably distinct code objects should be very unlikely to have the
same hash value. This bug affected our debugger before we worked around
it
17 matches
Mail list logo
