Changes by Davin Potts :
--
type: -> behavior
___
Python tracker
<http://bugs.python.org/issue24948>
___
___
Python-bugs-list mailing list
Unsubscrib
Changes by Davin Potts :
--
nosy: +jnoller, sbt
___
Python tracker
<http://bugs.python.org/issue24948>
___
___
Python-bugs-list mailing list
Unsubscribe:
Davin Potts added the comment:
If I understand your motivations correctly, I'd restate them as: you want a
mechanism for being immediately notified of an exception in a parent process
without waiting on any child processes of that parent to finish and furthermore
propose this should b
Changes by Davin Potts :
--
stage: needs patch -> patch review
___
Python tracker
<http://bugs.python.org/issue23992>
___
___
Python-bugs-list mailing list
Un
Davin Potts added the comment:
The patches make good sense to me -- I have no comments to add in a review.
I spent more time than I care to admit concerned with the idea that
error_callback (exposed by map_async which map sits on top of) should perhaps
be called not just once at the end but
Davin Potts added the comment:
@berker.peksag, @r.david.murray: Could I gently nudge one of you into
committing the final versions of these patches?
--
___
Python tracker
<http://bugs.python.org/issue23
Davin Potts added the comment:
To Antoine's point in issue24391, here too, these modifications to the format
of the repr are estimated to have very little impact or risk to breaking
existing code.
--
___
Python tracker
<http://bugs.py
Davin Potts added the comment:
Echoing Larry's insightful summary, it would not be particularly rewarding to
pursue a goal of making the whole world of reprs consistent. But as Antoine
and Serhiy began to point out, the multiprocessing module not only has its own
Event, Sema
Davin Potts added the comment:
This patch implements the majority opinion from issue24391 for the desired
format of the reprs produced by Event, Semaphore, BoundedSemaphore, and
Barrier. It provides tests around each, inspired by Serhiy's preliminary patch
for that same issue but adapte
Changes by Davin Potts :
--
dependencies: +Better repr for threading objects
___
Python tracker
<http://bugs.python.org/issue25066>
___
___
Python-bugs-list mailin
New submission from Davin Potts:
Inspired by issue24391 and the changes proposed to the threading module's reprs
for Event, Semaphore, BoundedSemaphore, and Barrier, the corresponding objects
in the multiprocessing module should have their reprs updated accordingly.
--
assignee:
Changes by Davin Potts :
--
status: open -> pending
versions: +Python 3.5
___
Python tracker
<http://bugs.python.org/issue25053>
___
___
Python-bugs-list mai
Davin Potts added the comment:
I have been able to reproduce the behavior you described under 3.5 under one
set of circumstances so far.
When attempting to use classes/functions/other not defined in an importable
module, an AttributeError is expected as you observed. The viability of that
Davin Potts added the comment:
@neologix: Budgeting time this week to have a proper look -- sorry I haven't
gotten back to it sooner.
--
___
Python tracker
<http://bugs.python.org/is
Davin Potts added the comment:
The 'crash' type is reserved for core dump type situations; 'behavior' is more
appropriate for the misbehavior your describe.
--
type: crash -> behavior
___
Python tracker
<http://
Changes by Davin Potts :
--
type: -> enhancement
___
Python tracker
<http://bugs.python.org/issue24475>
___
___
Python-bugs-list mailing list
Unsubscrib
Davin Potts added the comment:
Closing as there is no additional information forthcoming from the OP and per
the prior comments, Torsten's suggestion seems as helpful as anything that can
be offered without more info.
--
resolution: -> out of date
status: pending -
Davin Potts added the comment:
Triggering it regularly in a build farm indeed sounds like genuine pain.
@Paul or @vapier: In tracking down this issue, did you already create a
convenient way to repro the misbehavior that could be used in testing? Any
finalized patch that we make will need
Davin Potts added the comment:
Without further information from the OP, there is not much more we can do as
the problem may well originate with the user's compiled C code (which
circumstantially seems quite likely). Closing as out-of-date.
--
resolution: -> out of dat
Davin Potts added the comment:
At first blush it does appear there is potential for conflict because of how
the semaphore filename template was implemented -- that's a cool find. In
practice, I wonder how often this has actually bitten anyone in the real world.
The Linux world
Changes by Davin Potts :
--
stage: -> patch review
type: -> enhancement
___
Python tracker
<http://bugs.python.org/issue24033>
___
___
Python-bugs-list
Changes by Davin Potts :
--
nosy: +davin
type: crash -> behavior
___
Python tracker
<http://bugs.python.org/issue24202>
___
___
Python-bugs-list mailing list
Un
Changes by Davin Potts :
--
nosy: +davin
___
Python tracker
<http://bugs.python.org/issue24153>
___
___
Python-bugs-list mailing list
Unsubscribe:
Davin Potts added the comment:
@Ivan.K: Can you be more specific about which linux platform you are using?
To reproduce, should I use Ubuntu, Fedora, OpenSUSE, ... and which version of
that linux distro?
--
___
Python tracker
<h
Changes by Davin Potts :
--
nosy: +davin
___
Python tracker
<http://bugs.python.org/issue13044>
___
___
Python-bugs-list mailing list
Unsubscribe:
Davin Potts added the comment:
It is no longer possible to reproduce the described issue. Changes to the
relevant libraries since this issue was originally opened appear to have
addressed the cause. Going ahead with closing this issue as there have been no
further reports from the OP or
Davin Potts added the comment:
The issue may already be addressed for the OP and without further information
we don't know what or if anything needs pursuing. If new information surfaces,
a new issue should be opened.
--
resolution: -> out of date
status: pending -
Changes by Davin Potts :
--
nosy: +davin
___
Python tracker
<http://bugs.python.org/issue9782>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Davin Potts :
--
nosy: +davin
___
Python tracker
<http://bugs.python.org/issue21345>
___
___
Python-bugs-list mailing list
Unsubscribe:
Davin Potts added the comment:
The man pages for waitpid on OpenBSD 5.x do not suggest any meaningful value
will be returned in status when WNOHANG is requested and no child processes
have anything to report.
The following session attempts to exercise os.waitpid using Python 2.7.9 on an
Changes by Davin Potts :
--
nosy: +davin
___
Python tracker
<http://bugs.python.org/issue24033>
___
___
Python-bugs-list mailing list
Unsubscribe:
Davin Potts added the comment:
Serhiy: If my comments on your questions make sense, should we go ahead with
the patch as it is?
--
___
Python tracker
<http://bugs.python.org/issue23
Davin Potts added the comment:
@Luis: Before closing this bug, could you give a quick description of the fix
you put in place?
Two reasons:
1) Someone else encountering this frustration with similar needs might well
benefit from hearing what you did.
2) To provide evidence that there is
Davin Potts added the comment:
This is a nice example demonstrating what I agree is a problem with the current
implementation of close.
A practical concern with what I believe is being proposed in your trivial fix:
if the workers are engaged in very long-running tasks (and perhaps slowly
Davin Potts added the comment:
Though it's been discussed elsewhere, issue17560 is a good one where the matter
of "really big" objects are being communicated between processes via
multiprocessing. In it, Richard shares some detail about the implementation in
multiprocessing,
Davin Potts added the comment:
Closing this stale issue as out of date with no response from OP since request
months ago for enough info to be able to proceed.
--
resolution: -> out of date
status: pending -> closed
___
Python tracker
Davin Potts added the comment:
Closing this very stale issue as out of date with no response from OP since
request months ago for enough info to be able to proceed.
--
resolution: -> out of date
status: pending -> closed
___
Python tracker
Davin Potts added the comment:
Closing this very stale issue as out of date with no response from OP since
request months ago for enough info to be able to proceed.
--
resolution: -> out of date
status: pending -> closed
___
Python tracker
Davin Potts added the comment:
Serhiy: If I understand correctly what you suggest, calling sorted(it) or
list(it) would run the iterator all the way until it raises the SayWhenError
exception, triggering the self.assertRaises before it ever actually gets to
call the self.assertEqual or
Davin Potts added the comment:
Updating patch for default/3.5 and 3.4 branches to remove versionchanged
message on {Lock,RLock}.acquire per feedback from @berker.
--
Added file:
http://bugs.python.org/file38867/issue_23484_doc_locks_py35_and_py34_noverchange.patch
Davin Potts added the comment:
Same for 2.7 branch.
--
Added file:
http://bugs.python.org/file38868/issue_23484_doc_locks_py27_noverchange.patch
___
Python tracker
<http://bugs.python.org/issue23
Changes by Davin Potts :
--
nosy: +davin
___
Python tracker
<http://bugs.python.org/issue23852>
___
___
Python-bugs-list mailing list
Unsubscribe:
Davin Potts added the comment:
@berker: Sadly, I've read those descriptions in triaging.html more than once
and that part apparently did not stick in my head. Hopefully it will now --
thanks.
@r.david: Ok, cool -- I had been mentally associating more significance to one
versus the
Davin Potts added the comment:
@berker: I would have said this should not be marked an enhancement as the
proposed solution (in the patch) is to correct the errors in the documentation
to accurately describe the current implemented behavior. Does that make sense?
Whatever label we give it
Davin Potts added the comment:
@haypo: I didn't think that one through -- the consequences of that fragile
test are not a hang. It's unrelated.
--
___
Python tracker
<http://bugs.python.o
Davin Potts added the comment:
@haypo: Could you please take a look at applying my patches from issue23713 to
address an intermittent multiprocessing test failure? I don't know that it is
the sole cause, but it is indeed one potential source of the misbehavior.
--
nosy: +
Changes by Davin Potts :
--
nosy: +rhettinger
___
Python tracker
<http://bugs.python.org/issue18620>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Davin Potts :
--
nosy: +rhettinger
___
Python tracker
<http://bugs.python.org/issue23484>
___
___
Python-bugs-list mailing list
Unsubscribe:
Davin Potts added the comment:
Attaching patches for 3.5/default, 3.4, and 2.7 which update the documentation
on multiprocessing.Lock, RLock, Semaphore, and BoundedSemaphore to describe
their actual implemented behavior, replacing the existing, misleading claim
that they are clones of
Changes by Davin Potts :
Added file: http://bugs.python.org/file38703/issue_23484_doc_locks_py27.patch
___
Python tracker
<http://bugs.python.org/issue23484>
___
___
Pytho
Changes by Davin Potts :
--
versions: +Python 2.7, Python 3.4
___
Python tracker
<http://bugs.python.org/issue21342>
___
___
Python-bugs-list mailing list
Unsub
Davin Potts added the comment:
Since the time of its introduction in 2.6, a call to
multiprocessing.Lock.release on an already unlocked lock resulted in behavior
that did not match that of threading.Lock.release (which raised a thread.error
as far back as 2.4 and probably longer than that
Davin Potts added the comment:
Inheriting the priority from issue22634 which has been marked closed->duplicate
(duplicate of this issue).
Previously issue22634 was given a priority of "release blocker" by @pitrou.
Issue22634 described how this issue also afflicts 32-bit build
Davin Potts added the comment:
Attaching patch for this fragile test for 2.7 branch.
Patches have been put through test.regrtest on OS X 10.10 (64-bit), FreeBSD
10.1 i386 (32-bit), and Raspbian Debian (ARMv6) thus far.
--
stage: -> patch review
Added file:
http://bugs.python.
Davin Potts added the comment:
Attaching patch for this fragile test for default/3.5 and 3.4 branches.
Blame for implementing the fragile test falls to @davin. In my own defense,
@davin also discovered it in testing on FreeBSD 10.1 i386-RELEASE.
--
keywords: +patch
Added file:
http
New submission from Davin Potts:
test_imap_unordered_handle_iterable_exception fails intermittently on some
platforms due to the test being too rigid (fragile) about the order of the
items being iterated over which, as the name would imply, is not guaranteed.
Of the multiprocessing module&#
Davin Potts added the comment:
@siyuan: Duping it -- thanks for trying that patch out so quickly!
--
superseder: -> ctypes module doesn't build on FreeBSD x86
___
Python tracker
<http://bugs.python.org
Davin Potts added the comment:
No, it's premature to share the start of my patch.
Very much agreed on getting that input/insight -- sbt (multiprocessing module
maintainer and original author) was added to the nosy list yesterday too.
--
___
P
Davin Potts added the comment:
There is now a proposed patch on issue23042 which, having gone through those
changes, may well address this issue too.
Testing that patch on multiple platforms (including the RHEL variants relevant
here) would be much appreciated.
Thanks goes to @lemburg for
Changes by Davin Potts :
--
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue23042>
___
___
Python-bugs-list mailing list
Unsubscrib
Davin Potts added the comment:
Attaching a patch which enabled successful compilation of ctypes on FreeBSD
10.1 i386-RELEASE in each of default/3.5, 3.4, and 2.7 branches.
This patch attempts to fix the incomplete logic regarding Windows target
platforms in the ifdef's inside Modules/_c
Davin Potts added the comment:
Comparing this to issue23042, this same behavior appears on i386 releases of
FreeBSD 8.3 and 10.1 (the i386-RELEASE means it's 32-bit as opposed to 64-bit
build). Given that this issue is being triggered here with -m32 (triggers
building of 32-bit binaries
Davin Potts added the comment:
Reading issue22634 suggests that perhaps this issue is not limited to FreeBSD
-- issue22634 appears to suffer the same behavior on RHEL 6.4 and 5.5 when
compiling to 32-bit (the -m32 compiler flag is being used there
Davin Potts added the comment:
To provide supporting information, using the i386 release of FreeBSD 10.1:
* ctypes fails to build with the latest from Python 2.7 branch with the message:
build/temp.freebsd-10.1-RELEASE-i386-2.7-pydebug/usr/home/davin/pycoredev/cpython/Modules/_ctypes
Davin Potts added the comment:
This is closely related to issue23510. The two issues are reacting to the same
underlying inconsistency though in this issue the problem is more generally
(and clearly) stated whereas issue23510 is more concerned with the consequences
to using these as Context
Davin Potts added the comment:
Are you looking at the current code in the 2.7 branch or just at the code
committed in https://hg.python.org/cpython/rev/da5b370f41a1 (done as part of
issue13854)?
The code in 2.7 has since been updated and appears to use an exitcode of 1
whenever a str is
Davin Potts added the comment:
After pondering it for two days and coming back to it with hopefully "fresh
eyes", I believe that changing the for-loop to a while-loop is not overall
easier to understand -- I would lean towards keeping the for-loop.
I do think the change to the while
Davin Potts added the comment:
Per Richard's post from 1 year ago where he offers both explanation and an
example, ultimately concluding that things are working as intended, and because
there have been no objections or requests for clarification in the past year,
closing this and marki
Davin Potts added the comment:
Yes, setting -Werror::ResourceWarning would indeed cause the test to fail again.
A couple of options we could potentially adopt:
1. Decide to ignore anything extra in the file anytime any kind of "error"
filterwarning is present.
2. Decide to ignor
Changes by Davin Potts :
--
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue21779>
___
___
Python-bugs-list mailing list
Unsubscrib
Davin Potts added the comment:
Attaching patch for both 3.4 and default/3.5 (single file works for both) which
fixes the test to properly adjust for running under -Werror.
Whether -Werror is set or otherwise the equivalent of
'warnings.simplefilter("error", Warning)
Davin Potts added the comment:
Can the OP provide a runnable example to help us understand what they are
actually trying to do?
There is simply not enough information for us to go on here -- Torsten's
suggestion is a good one but we need more information to help any further.
--
Davin Potts added the comment:
Unable to reproduce on Ubuntu 12.04.5 with Python 2.7.8 and current libtk8.5
and libtcl8.5 releases using the attached hanger.py example.
Key findings to-date:
1. Posts to this issue have concluded that there exists a problem with thread-
and process-safety in
Davin Potts added the comment:
While the mockup of the code that you provided is of some help, it is still
unclear whether the problem could originate from your hand-rolled
serialization/de-serialization implementation or somewhere else. The traceback
you shared could even suggest an
Davin Potts added the comment:
I am unable to reproduce the described behavior using the script provided in
that gist using Python 2.7.9 on OS X 10.10 with scikit-learn 0.15.2, scipy
0.14.0, numpy 1.9.0.
For me, the sample code runs happily through to completion.
Can the OP still reproduce
Changes by Davin Potts :
--
nosy: +davin
___
Python tracker
<http://bugs.python.org/issue21779>
___
___
Python-bugs-list mailing list
Unsubscribe:
Davin Potts added the comment:
Attaching updated single patch for both default/3.5 and 3.4 to use Serhiy's
insightful simplification.
This updated patch has been tested on current Debian Hurd (see earlier comments
about full battery of tests there) and OS X 10.10 (full, verbose tests).
Davin Potts added the comment:
> No, I suggested to replace only the line that produces AttributeError now.
Ah! Sorry, I misunderstood and incorrectly assumed you were imagining the
import to happen at the top of the module.
I must confess I am hesitant about the idea of putting an imp
Changes by Davin Potts :
Added file:
http://bugs.python.org/file38363/issue_23051_revised_fix_and_tests_v27.patch
___
Python tracker
<http://bugs.python.org/issue23
Davin Potts added the comment:
Updated (1) the patch for default/3.5 and 3.4 and (2) the patch for 2.7 to
reflect recommendations from the review.
Thanks goes to Serhiy for the helpful review and especially the suggestion on
better future-proofing in the tests.
--
Added file:
http
Davin Potts added the comment:
Corrected patch for 3.4 and default/3.5 -- newly introduced test is now turned
on this time and the dangling weak references are properly addressed as well as
the reference to Empty. Nastiness.
Good save, Serhiy.
--
Added file:
http://bugs.python.org
Davin Potts added the comment:
Please keep in mind that this issue should only be encountered by people using
Python 3.x on a platform like Hurd (an unsupported platform) that has no
working sem_open implementation. If we try to imagine what Python 3.x users
should expect, it's that
Davin Potts added the comment:
Doing cleanup: This was marked as out of date in 2010 but somehow escaped
being marked closed. Closing now.
--
nosy: +davin
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.p
Davin Potts added the comment:
The original issue now appears addressed in the docs (thanks goes to Stuart and
Jesse) though it was not explicitly tracked here as a patch file.
The follow-on secondary issue from spongebob (if that is your real name) could
not be reproduced by Richard.
This
Changes by Davin Potts :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue20147>
___
___
Python-bugs-list mailing list
Unsubscrib
Davin Potts added the comment:
This same issue came up recently in issue23582. Really, it should have been
addressed in this issue here first and issue23582 marked as a duplicate of this
one but these things don't always happen in a synchronous or apparently-linear
fashion.
Adding to
Davin Potts added the comment:
Updates to both cx-freeze and multiprocessing in the meantime may likely have
addressed this since this issue was first reported. Granted, diagnosing issues
with cx-freeze are best directed to the cx-freeze project -- that is perhaps
where this issue should be
Davin Potts added the comment:
The discussion in issue23484 is leading to a recommendation that the docs be
changed to reflect the actual behavior of multiprocessing's Lock and its close
relatives.
As far back as 2.6.9, calling release() on an unlocked threading.Lock triggered
a thread.
Davin Potts added the comment:
Attaching a further revised patch for 3.4 and 3.5/default, now with cleaned-up
code style per the discussion in the review.
No changes are prompted for the patch to 2.7 as it only contained changes to
the docs and nothing code-related.
Thanks again goes to
Davin Potts added the comment:
The runnable example in the attached file, issue_23513_play.py, suggests a way
to preserve the inheritance of the Result class in any subclasses of Thing yet
leaves the definition of Thing.worker as the OP first had it (in the most
straightforward way).
In
Davin Potts added the comment:
To be fair, the docs in 2.7 do actually mention the use of 'block' instead of
'blocking' in acquire though it does so inside a "Note" block a bit later in
the docs after first claiming that multiprocessing.Lock is a "clone&q
Davin Potts added the comment:
In the docs for 2.7, multiprocessing.Lock refers to threading.Lock in which the
signature for acquire looks like:
threading.Lock.acquire([blocking])
However, in the current code in 2.7, Modules/_multiprocessing/semaphore.c
implements
Changes by Davin Potts :
--
nosy: +davin
___
Python tracker
<http://bugs.python.org/issue17140>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Davin Potts :
Added file:
http://bugs.python.org/file38273/issue_22853_only_test_import_lock_in_queue_py34_and_py35.patch
___
Python tracker
<http://bugs.python.org/issue22
Davin Potts added the comment:
Attaching a patch for 2.7 that applies Florian's fix and provides a test for it
as well.
Although the issue is not triggered on 3.4 or default (3.5), there is the
potential for regression there -- attaching a single patch that works for both
3.4 and 3
Davin Potts added the comment:
Confirmed that the issue can be reproduced under 2.7.9 on OS X 10.10.
It is not possible to reproduce the issue with default (3.5) -- taking a look
at what's different there, notably the import of is_exiting has moved to the
top of the queues module and
Davin Potts added the comment:
Adding an option does sound like a better possibility. Still, when I start
looking through the examples that psutil provides, it reminds me how this is
but one small piece of a much larger picture which psutil has done a nice,
focused job of working to address
Davin Potts added the comment:
Steve: FWIW, it looks like a good solution to me.
--
___
Python tracker
<http://bugs.python.org/issue18382>
___
___
Python-bug
Davin Potts added the comment:
Detecting the number of processors available to a process is a distinct concept
from reporting the number of processors present on a system. cpu_count is
currently focused on the latter.
Functionality to report the number of effectively-available processors is
Davin Potts added the comment:
I have a working patch that addresses this behavior and tests to go along with
it but am still working on updating the docs. Updating the docs in 2.7 in a
way to as closely match the docs in 3.4/3.5 as possible seems reasonable. It
remains unclear why
201 - 300 of 351 matches
Mail list logo
