Richard Oudkerk 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: ope
Richard Oudkerk added the comment:
The docs were patched in changeset 9fa52478b32b, so I will close.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Changes by Richard Oudkerk :
--
resolution: -> later
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Richard Oudkerk 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 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
___
Pytho
Richard Oudkerk added the comment:
OK, I'll close.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue8289>
___
___
Python-bugs-lis
Richard Oudkerk added the comment:
I'll close then.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue12897>
___
___
Python-bug
Changes by Richard Oudkerk :
--
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue3518>
___
___
Pyth
Richard Oudkerk 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.)
This new patch
New submission from Richard Oudkerk :
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: multiprocessing
Changes by Richard Oudkerk :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Richard Oudkerk :
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
New submission from Richard Oudkerk :
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 garbage colle
Richard Oudkerk 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 w
Richard Oudkerk 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, NUL
Richard Oudkerk 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.
The implementation in
Changes by Richard Oudkerk :
--
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 :
--
status: pending -> closed
___
Python tracker
<http://bugs.python.org/issue12774>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Richard Oudkerk :
--
status: pending -> closed
___
Python tracker
<http://bugs.python.org/issue12882>
___
___
Python-bugs-list mailing list
Unsubscri
Richard Oudkerk 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 reacquire
Richard Oudkerk 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 for multiprocessing.Condition is virtually
Richard Oudkerk 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
<http://bugs.python.
Richard Oudkerk 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? (T
Richard Oudkerk 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.html
1.45
Richard Oudkerk 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
<h
Richard Oudkerk added the comment:
Currently negative timeouts are treated as zero timeouts by Condition.wait().
The patches turns them into errors.
--
___
Python tracker
<http://bugs.python.org/issue15
Richard Oudkerk 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:
f.close_without_unlink()
with open(f.name
Richard Oudkerk 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. The
exception r
New submission from Richard Oudkerk :
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", "
Richard Oudkerk 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 out which one by
Richard Oudkerk 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 that send()
Richard Oudkerk 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 constants SH_DENYRD
Richard Oudkerk 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
Richard Oudkerk 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 that trying to reopen a
Richard Oudkerk 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 with FILE_SHARE_DELETE can
New submission from Richard Oudkerk :
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 using io.open() or
Richard Oudkerk 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 suite still runs
New submission from Richard Oudkerk :
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 is not open then
Richard Oudkerk added the comment:
This can probably be fixed by using _PyVerify_fd().
--
___
Python tracker
<http://bugs.python.org/issue15261>
___
___
Pytho
Richard Oudkerk 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
{}
--
___
P
Changes by Richard Oudkerk :
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Richard Oudkerk 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) :
INVALID_HANDLE_VALUE
Richard Oudkerk added the comment:
Sorry about that...
--
___
Python tracker
<http://bugs.python.org/issue15261>
___
___
Python-bugs-list mailing list
Unsub
New submission from Richard Oudkerk :
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 functio
New submission from Richard Oudkerk :
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, J
New submission from Richard Oudkerk :
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 extensions because
New submission from Richard Oudkerk :
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 added the comment:
The attached patch works for me.
--
keywords: +patch
Added file: http://bugs.python.org/file26395/build_ext.patch
___
Python tracker
<http://bugs.python.org/issue15
Richard Oudkerk 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
<http://bugs.python.org/issue15
Richard Oudkerk added the comment:
Updated patch. Old one broke test_distutils...
--
Added file: http://bugs.python.org/file26399/distutils-sysconfig.patch
___
Python tracker
<http://bugs.python.org/issue15
Richard Oudkerk added the comment:
Updated patch which does not fail test_distutils.
--
Added file: http://bugs.python.org/file26400/build_ext.patch
___
Python tracker
<http://bugs.python.org/issue15
Richard Oudkerk 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
f
Richard Oudkerk 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 tracker
<h
Richard Oudkerk 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') == '
Richard Oudkerk 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 only
Richard Oudkerk 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
Richard Oudkerk added the comment:
Forgot to remove some unnecessary code in patch.
--
Added file: http://bugs.python.org/file26427/sysconf.patch
___
Python tracker
<http://bugs.python.org/issue15
Richard Oudkerk 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 and build
Richard Oudkerk added the comment:
> I'd make get_config_var('srcdir') to be None for installed systems,
> because the source tree is not available there.
While playing with a version of the patch which returns None for non-source
builds, I found that distutils.suppo
Richard Oudkerk added the comment:
Can't you unbind without any changes to the C code by doing
def unbind(f):
if hasattr(f, '__func__'):
return f.__func__
self = getattr(f, '__self__', None)
if self is not None and not isinstan
Richard Oudkerk added the comment:
The problem is that os.wait() is returning when the wrong process exits.
You can fix this by specifying the pid you are waiting for by doing
"os.waitpid(pid, 0)" instead of "os.wait()".
Arguably os.popen() and subprocess.communicate() et
Richard Oudkerk added the comment:
Actually, if you replace
print(os.popen("uname").read())
with
f = os.popen("uname")
print(f.read())
f.close()
or
with os.popen("uname") as f:
print(f.read())
then things
New submission from Richard Oudkerk :
In the documentation on weakrefs there is the following quote
Note: Weak references to an object are cleared before the object’s
__del__() is called, to ensure that the weak reference callback
(if any) finds the object still alive.
But I think
Richard Oudkerk added the comment:
> The weakref is "dead" but it's still a weakref, and it can be used to
> e.g. index a container of existing weakrefs (cf. WeakSet,
> WeakKeyDictionary, WeakValueDictionary).
Ah.
I had assumed that since dead weakrefs were unhashable
Richard Oudkerk added the comment:
In Python 2.x, when the file object returned by popen() is garbage collected
the process is automatically waited on, collecting the pid of the process.
In Python 3.x a wrapper object is used whose close method wait on the pid.
This close method is *not
Richard Oudkerk added the comment:
A program which depends on the old behaviour would be broken on a
non-refcounted implementation of Python, so I would be inclined to say "won't
fix".
However, I think the following patch would restore the old behaviour
diff -r a970054a93fb
Changes by Richard Oudkerk :
--
nosy: +sbt
___
Python tracker
<http://bugs.python.org/issue6056>
___
___
Python-bugs-list mailing list
Unsubscribe:
Richard Oudkerk added the comment:
ISTM the simplest approach would be to just set self->args in
BaseException.__new__() (like in Georg's patch) but to ignore the possibility
that the user might later set self.args to something stupid "wrong":
diff -r 51ac5f06dd04 Objects/
Richard Oudkerk added the comment:
Is it possible that the use of test.support.gc_collect() in test_memoryview
made the difference?
--
___
Python tracker
<http://bugs.python.org/issue14
Changes by Richard Oudkerk :
--
nosy: +sbt
___
Python tracker
<http://bugs.python.org/issue14501>
___
___
Python-bugs-list mailing list
Unsubscribe:
Richard Oudkerk added the comment:
I think env is used for specifying the environment used by the child process
once it has started. env['PATH'] is not used by the parent process to find
program to run.
Having said that, maybe if you used "shell=True" as well then the s
Richard Oudkerk added the comment:
I see that the originally proposed patch is more or less what I suggested
above. Since this has been a critical issue for 5 years, I think such a
minimal patch should be committed even though it is not a complete solution.
It seems to me that the more
Richard Oudkerk added the comment:
You could just do
Server_1=TestServer(address=("127.0.0.1",5),authkey=b"passkey")
so this is probably a documentation issue. The examples in the documentation
should at least be updated.
--
__
Richard Oudkerk added the comment:
Any objection if I commit the last patch before the next beta? This is the one
which on installed Pythons have
get_config_var('srcdir') == os.path.dirname(get_makefile_filename())
on pos
Richard Oudkerk added the comment:
> Does get_config_var('srcdir') always return a string or sometimes None?
Always a string.
distutils.support._get_xxmodule_path() is one place which (currently) would
throw an exception if it
Richard Oudkerk added the comment:
I realize now that the idea of using object.__reduce__(..., 2) would not really
work since many exception classes use non-slot descriptors (unless '__slots__'
attributes were also added as hints of what to serialize).
I think there are two opti
Richard Oudkerk added the comment:
Here is a minimal patch against default.
It is a clear improvement on the current situation, even though it still cannot
handle the case
class Error(Exception):
def __init__(self, x):
Exception.__init__(self)
self.x = x
Changes by Richard Oudkerk :
Added file: http://bugs.python.org/file26537/init_args.patch
___
Python tracker
<http://bugs.python.org/issue1692335>
___
___
Python-bug
Richard Oudkerk added the comment:
ExceptionTests.testAttributes already checks the attributes of unpickled copies
(using all protocols).
--
___
Python tracker
<http://bugs.python.org/issue1692
Richard Oudkerk added the comment:
BTW, BaseException_init() has the code
Py_XDECREF(self->args);
self->args = args;
Py_INCREF(self->args);
Presumably the Py_XDECREF(self->args) would be better replaced by
Py_CLEA
Richard Oudkerk added the comment:
> Or you could simply Py_INCREF(args) before the Py_XDECREF...
But won't self->args point to a broken object while any callbacks triggered by
Py_XDECREF() are run?
An alternative would be
tmp = self->args;
self->args = args;
Richard Oudkerk added the comment:
Patch which adds fix for BaseException_init().
Actually this class of problem seem to be quite common.
BaseException_set_tb() appears to be affected too, as is the code in the
tutorial which introduces setters.
--
Added file: http
Richard Oudkerk added the comment:
> Richard, can the issue be closed?
I guess so (although the change could arguably be back ported).
Pickling of Exception classes is still somewhat dodgy because an example like
class Error(Exception):
def __init__(self, x):
Except
Changes by Richard Oudkerk :
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
type: crash -> behavior
___
Python tracker
<http://bugs.pytho
Richard Oudkerk added the comment:
> One example is 'srcdir': this value is only useful in the build tree and
> there currently is no clean way to signal that you are retrieving a
> value that is not useful.
In the particular case of 'srcdir', sysconfig.is_pyth
Richard Oudkerk added the comment:
> But I observe that the same script(with proper modification of file names)
> works very well under Linux. After I dive into the source code, I found
> Python use execvpe to invoke the child process which _will_ use the PATH
> variable t
Richard Oudkerk added the comment:
> What I understand you two as saying is that there seems to be an
> undocumented difference in execxxe between unix and windows which has been
> carried over to subprocess.
No. There is no difference between the platforms in the behaviour of
o
Richard Oudkerk added the comment:
Couldn't the preexec_fn argument of Popen be used instead?
--
nosy: +sbt
___
Python tracker
<http://bugs.python.org/is
Richard Oudkerk added the comment:
> Couldn't the preexec_fn argument of Popen be used instead?
Actually, since Python 3.2 you can just use "restore_signals=True".
--
___
Python tracker
<http://bugs.
New submission from Richard Oudkerk:
A patch with docs and tests for the idea I suggested on python-ideas:
http://comments.gmane.org/gmane.comp.python.ideas/15863
To repeat what I wrote there, the current issues with weakref callbacks include:
1. They are rather low level, and working out
Richard Oudkerk added the comment:
I would guess that the process has already terminated (or is being torn down)
but the timeout is not long enough to let the parent join child.
Let's see if increasing the timeout fixes the failures.
--
___
P
Richard Oudkerk added the comment:
Looks like it is fixed.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Richard Oudkerk added the comment:
> I don't quite understand the purpose of your suggestions. What can you do
> with it help, what you can not do with contextlib.ExitStack, atexit,
> __del__ method, weakref.WeakKeyDictionary or weakref.ref? I read the
> documentation, but t
Richard Oudkerk added the comment:
> For point 1: global weakref.WeakKeyDictionary is good store for weak refs
> with
> callbacks.
>
> global weakdict
> weakdict[kenny] = weakref.ref(kenny, lambda _: print("you killed kenny!"))
That depends on kenny being hasha
Richard Oudkerk added the comment:
Updated patch.
get() and put() replaced by peek() and detach(). Added isalive(). Now
finalizer class has no state, i.e. __slots__ == ().
--
Added file: http://bugs.python.org/file26701/finalize.patch
___
Python
Richard Oudkerk added the comment:
> In _make_callback, I still think the default error reporting mechanism
> should be kept. It can be improved separately.
New patch. This time I have got rid of _make_callback, and just given __call__
an ignored optional argument.
--
Adde
Richard Oudkerk added the comment:
> In the latest patch, what are "broken" and "priority" for?
They are for a subclass used by multiprocessing. But it is premature to worry
about subclassing, so I will take them out.
> Also, I would question why atexit is false b
Richard Oudkerk added the comment:
Might it be simpler to run doctest over the rst file from the relevant
unittest? (Perhaps with help from test.support.)
--
nosy: +sbt
___
Python tracker
<http://bugs.python.org/issue15
Richard Oudkerk added the comment:
> the occasional typos can be found by simply run `make doctest` every once
> in a while).
But doesn't "make doctest" attempt to run the doctests using Python 2.x
(because Sphinx does n
Richard Oudkerk added the comment:
An example from the output of "make doctest" which fails because Python 2.x is
being used:
**
File "library/multiprocessing.rst", line 453, in default
Failed example:
201 - 300 of 737 matches
Mail list logo
