Richard Oudkerk shibt...@gmail.com added the comment:
Here is an updated patch which also modifies distutils.sysconfig.
For installed pythons on posix systems it makes
get_config_var('srcdir') == os.path.dirname(get_makefile_filename())
(The older patches would give the same result only
Richard Oudkerk shibt...@gmail.com added the comment:
Forgot to remove some unnecessary code in patch.
--
Added file: http://bugs.python.org/file26427/sysconf.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15364
Richard Oudkerk shibt...@gmail.com added the comment:
I suspect the problem is related to http://bugs.python.org/issue15298.
Basically the global sysconfig module caches the results of parsing Makefile in
Lib/_sysconfigdata.py. This can cause you to get the config vars from an old
configure
Richard Oudkerk shibt...@gmail.com added the comment:
Updated patch which clarifies that for an installed python on a posix system,
get_config_var('srcdir') == get_path('stdlib').
Eg, if sys.executable == '/usr/local/bin/python3.3' then
get_config_var('srcdir') == '/usr/local/lib/python3.3
Richard Oudkerk shibt...@gmail.com added the comment:
Beyond that, I don't understand why the patch behavior depends on
whether the srcdir is an absolute path or not.
The os.path.isabs() test is actually redundant since os.path.join(base, srcdir)
== srcdir if srcdir is an absolute path. I
New submission from Richard Oudkerk shibt...@gmail.com:
With unix, and a source build, sysconfig.get_config_var('srcdir') and
sysconfig.get_path('include') misbehave:
user@mint-vm ~/Repos/cpython $ cd /
user@mint-vm / $ ~/Repos/cpython/python
Python 3.3.0b1 (default:671894ae19a2, Jul 16
New submission from Richard Oudkerk shibt...@gmail.com:
For Unix I follow the practice suggested in README of running configure from a
subdir of the main python directory, eg
mkdir release
cd release
../configure
make
But if I create a venv then I cannot use it to compile C
New submission from Richard Oudkerk shibt...@gmail.com:
On Windows I can't use a source build of Python to create a venv which will
compile C extensions because pyconfig.h cannot be found. For example
running build
running build_ext
building 'demo' extension
creating build
Richard Oudkerk shibt...@gmail.com added the comment:
The attached patch works for me.
--
keywords: +patch
Added file: http://bugs.python.org/file26395/build_ext.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15367
Richard Oudkerk shibt...@gmail.com added the comment:
The attached patch seems to fix the problem.
--
keywords: +patch
Added file: http://bugs.python.org/file26397/distutils-sysconfig.patch
___
Python tracker rep...@bugs.python.org
http
Richard Oudkerk shibt...@gmail.com added the comment:
Updated patch. Old one broke test_distutils...
--
Added file: http://bugs.python.org/file26399/distutils-sysconfig.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Richard Oudkerk shibt...@gmail.com added the comment:
Updated patch which does not fail test_distutils.
--
Added file: http://bugs.python.org/file26400/build_ext.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15367
Richard Oudkerk shibt...@gmail.com added the comment:
I don't recall what the issue was the resulted in the check-in that you
mention.
I think it was http://bugs.python.org/issue8577. The issue was about having
srcdir != builddir. The initial patch caused a test failure, and 356d0ea8ea34
Richard Oudkerk shibt...@gmail.com added the comment:
In the attached patch _safe_realpath() is only called after calculating the
absolute path for srcdir.
--
keywords: +patch
Added file: http://bugs.python.org/file26407/sysconf.patch
___
Python
New submission from Richard Oudkerk shibt...@gmail.com:
If I create a venv on Windows called py3 then py3/Scripts/Activate.ps1
defines the prompt to be
function prompt {
Write-Host -NoNewline -ForegroundColor Green [(py3) ]
_OLD_VIRTUAL_PROMPT
}
However this prompt
Richard Oudkerk shibt...@gmail.com added the comment:
Many os functions started to accept file descriptors.
I don't know how many are available on Windows...
On Windows os.stat() seems to be the only one:
os.supports_fd
{built-in function stat
Changes by Richard Oudkerk shibt...@gmail.com:
--
resolution: - fixed
stage: needs patch - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15261
Richard Oudkerk shibt...@gmail.com added the comment:
Every use of _get_osfhandle() should be guarded by _Py_VerifyFd().
Grepping through the source it seems that that is now true, but we could
instead use
#define _PY_GET_OSFHANDLE(fd) _Py_VerifyFd(fd) ? _get_osfhandle(fd
Richard Oudkerk shibt...@gmail.com added the comment:
Sorry about that...
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15261
___
___
Python
New submission from Richard Oudkerk shibt...@gmail.com:
In Python 3.3 (but not earlier) os.stat() is documented to work with file
descriptors. (os.path.exists() also works with fds since it is implemented in
terms of os.stat(), although that is *not* documented.)
However, on Windows if fd
Richard Oudkerk shibt...@gmail.com added the comment:
This can probably be fixed by using _PyVerify_fd().
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15261
New submission from Richard Oudkerk shibt...@gmail.com:
On Unix, files (unless specifically locked) can be renamed and deleted while
file descriptors for the file remain open. The file descriptors remain valid
even after deletion of the file.
On Windows this is not possible for files opened
Richard Oudkerk shibt...@gmail.com added the comment:
I have opened Issue #15244 with a patch to add a share module to the stdlib.
After monkey patching builtins.open(), io.open() and os.open() to be
equivalents using FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE, the
regression test
Richard Oudkerk shibt...@gmail.com added the comment:
I wrote in an earlier message that a file opened with O_TEMPORARY must be
reopened with O_TEMPORARY. This is not quite accurate.
Using O_TEMPORARY causes the FILE_SHARE_DELETE sharing mode to be used, and a
file currently opened
Richard Oudkerk shibt...@gmail.com added the comment:
Then I doubt this is a bug in Python.
If your class does not override __reduce__, __reduce_ex__ or
__getstate__/__setstate__, then it is probably one of the attributes of your
instance which is causing the problem. You could try to find
Richard Oudkerk shibt...@gmail.com added the comment:
I have repaired my class so that it pickles properly, but that does not
resolve the issue that if you send a non-picklable object through a pipe,
it should raise an error, rather than hang.
What do you mean by hang? Do you mean
Richard Oudkerk shibt...@gmail.com added the comment:
The webpage
http://msdn.microsoft.com/en-us/library/aa273350(v=vs.60).aspx
describes the sopen() function which is like open() but has an extra shflag
parameter for specifying the sharing allowed.
If sopen() and the associated
Richard Oudkerk shibt...@gmail.com added the comment:
Agreed. Richard: do you have time to put something together?
I'm happy to try if you don't.
I'm looking into it.
Unfortunately, it seems that you need to use non-default flags when reopening a
shared file. Eg, if the file is currently
Richard Oudkerk shibt...@gmail.com added the comment:
I checked the source in
c:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/crt/src/open.c
and it seems that on Windows open() is more or less implemented as a wrapper of
sopen(..., ..., SH_DENYNO, ...).
So the only reason
Richard Oudkerk shibt...@gmail.com added the comment:
Rather than add a NamedTemporaryFile.delete_after() classmethod, would it not
be simpler to just add a close_without_unlink() method to NamedTemporaryFile?
with NamedTemporaryFile() as f:
write to f
Richard Oudkerk shibt...@gmail.com added the comment:
What type of object did you try to send, and how can the problem be reproduced?
There are plenty of types which don't support pickling, and where pickling only
succeeds in producing invalid data which cannot be successfully unpickled
New submission from Richard Oudkerk shibt...@gmail.com:
If you subclass OSError without calling OSError.__init__() then you can get a
crash. For example
Python 3.3.0b1 (default:cfbe51e66749, Jun 30 2012, 20:50:54) [MSC v.1600 32
bit
(Intel)] on win32
Type help, copyright, credits
Richard Oudkerk shibt...@gmail.com added the comment:
Currently negative timeouts are treated as zero timeouts by Condition.wait().
The patches turns them into errors.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15139
Richard Oudkerk shibt...@gmail.com added the comment:
On 32 bit linux in a VM I get
BEFORE
allocation 0.125
acquire/release 0.434
AFTER
allocation 0.109 (-13%)
acquire/release 0.346 (-20%)
--
nosy: +sbt
___
Python tracker
Richard Oudkerk shibt...@gmail.com added the comment:
The old version was
243 __inline static void _cond_signal(COND_T *cond) {
244 /* NOTE: This must be called with the mutex held */
245 if (cond-n_waiting 0) {
246 if (!ReleaseSemaphore(cond-sem, 1, NULL))
247
Richard Oudkerk shibt...@gmail.com added the comment:
Standard condition variables have the following guarantees:
* if there are any waiters then signal()/notify() will awaken at least one of
them;
* if there are any waiters then broadcast()/notify_all() will awaken all of
them
Changes by Richard Oudkerk shibt...@gmail.com:
--
resolution: - fixed
stage: needs patch - committed/rejected
status: open - closed
title: multiprocessing should use more context manager - Use context manager
protocol for more multiprocessing types
Changes by Richard Oudkerk shibt...@gmail.com:
--
status: pending - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12774
___
___
Python-bugs
Changes by Richard Oudkerk shibt...@gmail.com:
--
status: pending - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12882
___
___
Python-bugs
Richard Oudkerk shibt...@gmail.com added the comment:
Let me elaborate: the GIL can perhaps suffer lost wakeups from time to
time. The Lock API certainly shouldn't.
I think with FORCE_SWITCHING defined (the default?) it is not possible for the
thread releasing the GIL to immediately
Richard Oudkerk shibt...@gmail.com added the comment:
The implementation in condvar.h is basically the same as one of the attempts
mentioned in
http://birrell.org/andrew/papers/ImplementingCVs.pdf
(Listing 2 fixed to use non-binary semaphores.)
The implementation
Richard Oudkerk shibt...@gmail.com added the comment:
The notes should also mention that PyCOND_SIGNAL() and PyCOND_BROADCAST() must
be called while holding the mutex. (pthreads does not have that restriction.)
--
___
Python tracker rep
Richard Oudkerk shibt...@gmail.com added the comment:
It's an interesting article Richard, but I don't see how their 2nd attempt
solves the problem. All it does is block the thread doing the Signal(),
not other threads, from stealing the wakeup.
Do you mean the listing on page 5
Richard Oudkerk shibt...@gmail.com added the comment:
1.41 Generic emulations of the pthread_cond_* API using
1.42 earlier Win32 functions can be found on the Web.
1.43 The following read can be edificating (or not):
1.44 http://www.cse.wustl.edu/~schmidt/win32-cv-1
New submission from Richard Oudkerk shibt...@gmail.com:
Multiprocessing's process pool originally used a finalizer to shutdown the pool
when the pool object is garbage collected.
Since the maxtasksperchild feature was added, the worker_handler thread holds a
reference to the pool, preventing
Richard Oudkerk shibt...@gmail.com added the comment:
Py_LOCAL_INLINE(int)
_PyCOND_WAIT_MS(PyCOND_T *cv, PyMUTEX_T *cs, DWORD ms)
{
DWORD wait;
cv-waiting++;
PyMUTEX_UNLOCK(cs);
/* lost wakeup bug would occur if the caller were interrupted here,
* but we are safe because we
Changes by Richard Oudkerk shibt...@gmail.com:
--
resolution: - fixed
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14059
New submission from Richard Oudkerk shibt...@gmail.com:
There are some types which should support the context manager protocol:
- connection objects
- listener objects
- pool objects
--
messages: 162776
nosy: sbt
priority: normal
severity: normal
stage: needs patch
status: open
title
Changes by Richard Oudkerk shibt...@gmail.com:
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13841
Richard Oudkerk shibt...@gmail.com added the comment:
The trivial patch of replacing exit() by sys.exit() caused manager processes to
be terminated after a short timeout. (It is inconvenient that in Python there
is no way for a non-main thread to request immediate shutdown of the process
Richard Oudkerk shibt...@gmail.com added the comment:
Thanks for the patch, I have applied it. (I don't think there was a problem
with the promotion rules because res was a never converted to UINT32.)
--
resolution: - fixed
stage: - committed/rejected
status: open - closed
Richard Oudkerk shibt...@gmail.com added the comment:
The docs were patched in changeset 9fa52478b32b, so I will close.
--
resolution: - fixed
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http
Changes by Richard Oudkerk shibt...@gmail.com:
--
resolution: - later
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10037
Richard Oudkerk shibt...@gmail.com added the comment:
I don't think there is any problem here since you have control over which
arguments you pass to __init__.
Without a reason why that is not a solution I will eventually close the issue
as rejected.
--
resolution: - rejected
stage
Richard Oudkerk shibt...@gmail.com added the comment:
Unless you have a reason why imap() does not solve the problem I will
eventually close the issue as rejected.
--
resolution: - rejected
stage: - committed/rejected
status: open - pending
Richard Oudkerk shibt...@gmail.com added the comment:
OK, I'll close.
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8289
Richard Oudkerk shibt...@gmail.com added the comment:
I'll close then.
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12897
Changes by Richard Oudkerk shibt...@gmail.com:
--
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3518
Richard Oudkerk shibt...@gmail.com added the comment:
If you want lazy operation then you should use imap(f, it[, chunksize]) rather
than using map_async(f, it).
This will return an iterator rather than a list. Also, the iterator's next()
method has a timeout argument. (chunksize
Changes by Richard Oudkerk shibt...@gmail.com:
--
resolution: - out of date
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7474
Richard Oudkerk shibt...@gmail.com added the comment:
As long as you don't pass the arguments on to Process.__init__() when you call
it there should be no problem.
The following program works, but will fail with RuntimeError if you uncomment
the comment line:
from multiprocessing import
Richard Oudkerk shibt...@gmail.com added the comment:
One issue with sys.exit() is that it only makes the current thread exit.
Even when called in the main thread, the program will wait for non-daemon
threads to finish. A closer equivalent to terminate() would be
os.kill(os.getpid
Changes by Richard Oudkerk shibt...@gmail.com:
--
nosy: +sbt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10133
___
___
Python-bugs-list mailing
Richard Oudkerk shibt...@gmail.com added the comment:
I think this issue can be closed, the worker handler is simply borked and
we could open up a new issue deciding how to fix it (merging billiard.Pool
or someting else).
OK. I am not sure which option under Resolution should be chosen
Richard Oudkerk shibt...@gmail.com added the comment:
Ah, a working 'fork server' would be just as good.
Only problem is that it depends on fd passing which is apparently broken on
MacOSX.
Btw, Billiard now supports running Pool without threads, using
epoll/kqueue/select instead. So
Changes by Richard Oudkerk shibt...@gmail.com:
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12157
Changes by Richard Oudkerk shibt...@gmail.com:
--
resolution: - fixed
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13854
Richard Oudkerk shibt...@gmail.com added the comment:
The warning no longer appears for the 3.x branch. I think it was changeset
e54adf13e7a6 which only modified the test suite.
I don't think it is worth backporting to 3.2.
--
nosy: +sbt
resolution: - fixed
stage: needs patch
Changes by Richard Oudkerk shibt...@gmail.com:
--
nosy: +sbt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13854
___
___
Python-bugs-list mailing
Changes by Richard Oudkerk shibt...@gmail.com:
--
nosy: +sbt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12157
___
___
Python-bugs-list mailing
Changes by Richard Oudkerk shibt...@gmail.com:
--
nosy: +sbt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10037
___
___
Python-bugs-list mailing
Richard Oudkerk shibt...@gmail.com added the comment:
It is not clear to me how to reproduce the bug.
When you say letting the workers terminate themselves do mean calling
sys.exit() or os._exit() in the submitted task? Are you trying to get the
result of a task which caused the worker
Richard Oudkerk shibt...@gmail.com added the comment:
The attached patch uses memoryview instead of ctypes.
If the patch for Issue #14953 (reimplementing RawArray/RawValue in terms of
memoryview) is applied, then it could be simplified a bit.
--
Added file: http://bugs.python.org
Richard Oudkerk shibt...@gmail.com added the comment:
The Windows buildbots were failing compilation.
I've added Object/namespaceobject.c and Include/namespaceobject.h to
PCbuild/pythoncore.vcxproj in changeset ee7cd7d51ed6.
--
nosy: +sbt
Richard Oudkerk shibt...@gmail.com added the comment:
Lesha, the problems about magical __del__ methods you are worried about
actually have nothing to do with threading and locks. Even in a single
threaded program using fork, exactly the same issues of potential corruption
would be present
Richard Oudkerk shibt...@gmail.com added the comment:
conn = MySQLConn()
start_thread1(conn)
start_thread2(conn):
while True:
if os.fork() == 0: # child
raise Exception('doom') # triggers destructor
There is no guarantee here that the lock will be held at the time
Richard Oudkerk shibt...@gmail.com added the comment:
I don't think there is anything special about PriorityQueue.
There is a similar concerning the use of the Python implementation of RLock in
signal handlers -- see http://bugs.python.org/issue13697.
Maybe the signal handler should
Richard Oudkerk shibt...@gmail.com added the comment:
Attached is an updated version of Charles-François's reinit_locks.diff.
Changes:
* Handles RLock by assuming that if self-count != 0 when we acquire
the lock, then the lock must have been reinitialized by
PyThread_ReInitLocks
Richard Oudkerk shibt...@gmail.com added the comment:
a) fork() is called with the DB lock held by thread1.
b) Some time passes before the child gets to exec().
c) In that time, the child's thread2 gets to doWork().
d) Simultaneously, the parent's doWork is still running and holding a lock
Richard Oudkerk shibt...@gmail.com added the comment:
Is there any particular reason not to merge Charles-François's
reinit_locks.diff?
Reinitialising all locks to unlocked after a fork seems the only sane
option.
I agree with this.
I haven't looked at the patch very closely. I
Changes by Richard Oudkerk shibt...@gmail.com:
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14930
Richard Oudkerk shibt...@gmail.com added the comment:
It seems the real issue here is that buffer objects are picklable (depending on
protocol) but the resulting string is not unpicklable.
There are probably lots of other examples where this happens: for instance
Exception subclasses which do
New submission from Richard Oudkerk shibt...@gmail.com:
The attached patch enables creation of shared objects allocated from shared
memory using memoryview objects instead of ctypes.
This enables the use of shared memory on systems where ctypes is unavailable.
The new functions/classes
Richard Oudkerk shibt...@gmail.com added the comment:
New patch.
--
Added file: http://bugs.python.org/file25742/memoryview-weakref.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14930
Richard Oudkerk shibt...@gmail.com added the comment:
In the test, you should call gc.collect() so that it works on non-
reference counted implementations.
I did think about using gc.collect(), but I was not sure whether it was
guaranteed to collect everything possible if you only call
Richard Oudkerk shibt...@gmail.com added the comment:
Updated patch.
--
Added file: http://bugs.python.org/file25744/memoryview-weakref.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14930
Changes by Richard Oudkerk shibt...@gmail.com:
--
nosy: +sbt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13797
___
___
Python-bugs-list mailing
New submission from Richard Oudkerk shibt...@gmail.com:
The attached patch makes memoryview objects weakrefable.
The reason I would like them to be weakrefable is so that I can manage the
finalization and pickling of memoryview objects which wrap shared mmap segments.
(It would be even better
Richard Oudkerk shibt...@gmail.com added the comment:
RawValue uses ctypes, right? That's problematic for platforms which don't
support ctypes.
Are there many posix systems (we care about) where ctypes doesn't work?
It would be fairly easy to use memoryview instead of ctypes. (In fact
Changes by Richard Oudkerk shibt...@gmail.com:
--
resolution: - fixed
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12098
Changes by Richard Oudkerk shibt...@gmail.com:
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9400
Richard Oudkerk shibt...@gmail.com added the comment:
Without more information I will close this.
--
resolution: - invalid
stage: - committed/rejected
status: open - pending
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Richard Oudkerk shibt...@gmail.com added the comment:
I'll, remember that in future;-)
Closing.
--
resolution: - fixed
stage: - committed/rejected
status: open - closed
type: crash - behavior
___
Python tracker rep...@bugs.python.org
http
Changes by Richard Oudkerk shibt...@gmail.com:
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12091
Changes by Richard Oudkerk shibt...@gmail.com:
--
resolution: - fixed
stage: commit review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14548
Richard Oudkerk shibt...@gmail.com added the comment:
The patch was applied to 3.x branch in 0aa8af79359d and partially backported to
2.7 in 26bbff4562a7 - see #9400.
I will close.
--
nosy: +sbt
resolution: - fixed
stage: - committed/rejected
status: open - closed
Richard Oudkerk shibt...@gmail.com added the comment:
This is a duplicate of #9244 and #9400 which have been fixed by wrapping
unpicklable exceptions in picklable exceptions.
The larger issue of many exception classes being unpicklable, is dealt with in
#1692335.
--
resolution
Changes by Richard Oudkerk shibt...@gmail.com:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13751
___
___
Python-bugs
Richard Oudkerk shibt...@gmail.com added the comment:
_eintr_retry was removed by 99ef4501205b.
--
resolution: - out of date
stage: - committed/rejected
status: open - closed
type: - behavior
___
Python tracker rep...@bugs.python.org
http
Richard Oudkerk shibt...@gmail.com added the comment:
(1) Good catch. I suspect that this could be mitigated even if we cared
about LinuxThreads. I haven't looked, but there's got to be a way to
determine if we are a thread or a fork child.
Using a generation count would probably work just
601 - 700 of 736 matches
Mail list logo
