Chris Jerdonek added the comment:
> I note that there is no documented way to retrieve the cancel message
Does retrieving it from the CancelledError that is bubbling up suffice? Or do
you need to be able to obtain it from the future object?
--
nosy: +chris.jerdo
Chris Jerdonek added the comment:
> I'm not sure yet (if anything I'd need it for a task, not a future).
(By future, I also meant task, as task inherits from future.) For now, I think
it would be safer to get the message from the CancelledError, if possible,
since how it gets t
Chris Jerdonek added the comment:
Andrew, the approach I described would I feel be much better. It would result
in more concise, less verbose tracebacks, as opposed to more verbose -- not
just because the message won't be repeated, but also because it eliminates the
unneeded creati
Chris Jerdonek added the comment:
I don't really understand all the hate around the idea of a cancel message. One
reason it's useful is that it provides a simple way to say *why* something is
being cancelled or *what* is cancelling it. It provides additional context to
the excepti
Chris Jerdonek added the comment:
For future reference, with Andrew's change merged above, the traceback for the
example snippet in my message above:
https://bugs.python.org/issue45390#msg403570
is now the following. Observe that (1) the call to sleep() continues to be
present, b
New submission from Chris Jerdonek :
The logging module errors out if the multiprocessing module is not finished
loading when logging.log() is called.
This can happen, for example, if a custom import hook is defined that causes
third-party code to execute when the multiprocessing module gets
Changes by Chris Jerdonek :
--
nosy: +vinay.sajip
___
Python tracker
<http://bugs.python.org/issue8200>
___
___
Python-bugs-list mailing list
Unsubscribe:
Chris Jerdonek added the comment:
Reversing the if-else in Florent's suggestion seems to address points (1) and
(2). Is there a reason to set and check an mp variable rather than simply
having the try-except block?
if not logMultiprocessing:
self.processName = None
else:
# E
Chris Jerdonek added the comment:
I agree. Thanks!
--
___
Python tracker
<http://bugs.python.org/issue8200>
___
___
Python-bugs-list mailing list
Unsubscribe:
Chris Jerdonek added the comment:
FYI, I verified the fix in my local environment. Thanks again.
--
___
Python tracker
<http://bugs.python.org/issue8
Chris Jerdonek added the comment:
I was also hit by this today.
For the sake of clarity, I will restate two of the scenarios that have been
mentioned in this discussion:
(1) An ImportError raised whilst importing a module (original issue)
(2) A sub-module not existing.
I think the error
New submission from Chris Jerdonek :
It would be nice if the error message for an AttributeError could include the
module name when getting from a module -- just like it does for getting from a
class.
This would make the message more helpful. For example, it would help in
diagnosing issues
Chris Jerdonek added the comment:
> I think in both cases the error text should state not just what module was
> being imported but also what module was being imported from
FYI, I filed the following report partly in response to some of the comments I
made above:
http://bugs.pyth
Chris Jerdonek added the comment:
This patch implements Michael's suggestion (but not the ErrorHolder part):
http://bugs.python.org/issue7559#msg97462
The unit tests all pass with no change. If this approach looks good to you, I
can add a unit test to the patch that checks that this bu
Chris Jerdonek added the comment:
Great -- thanks a lot for taking a stab at this!
--
___
Python tracker
<http://bugs.python.org/issue8297>
___
___
Python-bug
Changes by Chris Jerdonek :
--
versions: +Python 2.6
___
Python tracker
<http://bugs.python.org/issue8297>
___
___
Python-bugs-list mailing list
Unsubscribe:
Chris Jerdonek added the comment:
Rietveld link: http://codereview.appspot.com/810044/show
This patch changes unittest.TestLoader.loadTestsFromName() so that ImportErrors
will bubble up when importing from a module with a bad import statement.
Before the method raised an AttributeError
Chris Jerdonek added the comment:
Thanks, David. Sorry about that. The test probably requires one additional
level of nesting so that "parts_copy" is not False:
+if not parts_copy or not module_not_found:
Chris Jerdonek added the comment:
FYI, there seems to be a bug in the code cited above:
http://twistedmatrix.com/trac/browser/trunk/twisted/python/reflect.py#L382
For example, _importAndCheckStack('package.subpackage.module') raises
_NoModuleFound in the following scenario
Chris Jerdonek added the comment:
Four failing unit tests (context code can use clean-up).
--
Added file: http://bugs.python.org/file16819/_patch-7559-4-unittests.diff
___
Python tracker
<http://bugs.python.org/issue7
Chris Jerdonek added the comment:
The new unit tests pass with this patch (minor clean-up still needed).
--
Added file: http://bugs.python.org/file16822/_patch-7559-5.diff
___
Python tracker
<http://bugs.python.org/issue7
Chris Jerdonek added the comment:
Thanks for your suggestions on the test code. I will do that.
It seems like the hard-coded approach would be more brittle. For example, if
someone wants to replace __import__ with their own, e.g.
old__import__ = __builtins__.__import__
def
Chris Jerdonek added the comment:
> I think you can simplify them a bit. For example, you can use assertRaises.
Actually, assertRaises doesn't seem to permit checking error text. That may be
one reason why try-except-else is being used instead th
Chris Jerdonek added the comment:
Patch update: added unit test to cover replacing __import__, incorporated R.
David Murray's suggestion to use test_support.test_cwd(), and overall code
clean-up.
Also uploaded as Patch 3 to--
http://codereview.appspot.com/810044/show
--
Added
New submission from Chris Jerdonek :
The "builtins" module referenced in the Python 2.6 __import__ documentation
does not seem to exist in Python 2.6:
http://docs.python.org/library/functions.html#__import__
These should probably be changed to __builtin__:
http://docs.python.o
Changes by Chris Jerdonek :
--
assignee: -> georg.brandl
components: +Documentation
nosy: +georg.brandl
___
Python tracker
<http://bugs.python.org/iss
Chris Jerdonek added the comment:
Replaced "builtins" with "__builtin__". Also inserted a missing "the".
--
keywords: +patch
Added file: http://bugs.python.org/file16870/_issue-8370-1.diff
___
Python tracker
<
Chris Jerdonek added the comment:
Thanks for the info and quick response. Then this should probably also be
applied to trunk (Python 2.7).
--
versions: +Python 2.7
___
Python tracker
<http://bugs.python.org/issue8
Chris Jerdonek added the comment:
Would it make sense to put a "New in version 3.1" at the top of this page:
http://docs.python.org/py3k/library/builtins.html
(perhaps also with a note explaining that the module replaces __builtin__). I
actually wasn't able to confirm when
Changes by Chris Jerdonek :
--
assignee: michael.foord -> cjerdonek
___
Python tracker
<http://bugs.python.org/issue7559>
___
___
Python-bugs-list mai
Chris Jerdonek added the comment:
> I think this is the same as issue37712.
This issue was first reported as issue24959. It would be better to close the
newer issues as duplicates of the first one, instead of keeping all the
duplicates open. Otherwise, the history and discussion g
Chris Jerdonek added the comment:
> So maybe we should change the terminology while we’re at it.
When math is taught to elementary school students in the US, it's called "order
of operations": https://en.wikipedia.org/wiki/Order_of_operations
Since this was raised in the co
Change by Chris Jerdonek :
--
nosy: +chris.jerdonek
___
Python tracker
<https://bugs.python.org/issue44112>
___
___
Python-bugs-list mailing list
Unsubscribe:
Chris Jerdonek added the comment:
> This issue is not solved.
Yes, nothing was changed. After diagnosing this issue and trying some things
out in a draft PR, my conclusion is that an asyncio maintainer really needs to
weigh in on what to do (especially Andrew who authored the class).
Chris Jerdonek added the comment:
> MultiLoopChildWatcher must ensures that the event loop is awaken when it
> receives a signal by using signal.setwakeup(). This is done by
> _UnixSelectorEventLoop.add_signal_handler(). Maybe MultiLoopChildWatcher
> could reuse this function,
Chris Jerdonek added the comment:
Thanks, Irit. Can you show how your patch behaves using some representative
examples (maybe using arrow examples from above)? And if it behaves differently
from Dennis's patch, can you include an example showing that
Chris Jerdonek added the comment:
Yes, that seems like a good approach. And how about with Serhiy's example from
above?
> If there is a chain A -> B -> C -> D -> E, after assignment C.__context__ = A
> ...
--
___
Chris Jerdonek added the comment:
That's okay. I didn't mean to suggest I thought your patch needed to handle
that case or that we needed to decide it before moving forward. I was just
wondering what would happen with your patch with it, even if it means a hang.
Or were you s
Chris Jerdonek added the comment:
> the result is C -> A -> B -> C
Did you mean C -> A -> B?
By the way, if you applied to this example your reasoning that PyErr_SetObject
shouldn't try to fix user bugs, should this example instead be C -> A -> B -> C
-&g
Chris Jerdonek added the comment:
> No, I meant C -> A -> B -> C -> A
Oh, good. I support your reasoning and approach, by the way.
--
___
Python tracker
<https://bugs.pyt
Chris Jerdonek added the comment:
Okay, I'll close the issue and update it to reflect that it was restricted to
the narrower, originally reported issue.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
title: exception chain cycles cau
Chris Jerdonek added the comment:
> Preventing creation of the loop will fix all other code that iterate the
> __context__ chain.
We can still do / discuss that following Irit's proposed change, which is an
improvement, IMO.
--
___
Chris Jerdonek added the comment:
Out of curiosity, is the failure deterministic in environments where it fails?
If not, what is the source of the indeterminism -- some kind of race condition
or something else?
--
nosy: +chris.jerdonek
___
Python
Chris Jerdonek added the comment:
> Maybe it's a very precise threshold which triggers the issue. Between Linux
> and macOS, the site module executes different code paths which produce
> different GC counters.
> Sometimes, the GC must happen in a very precise line, one
Chris Jerdonek added the comment:
"How does this explain it not being non-deterministic on" -> "How does this
explain it not being deterministic on"
--
___
Python tracker
<https://
Chris Jerdonek added the comment:
Last question: might trying different values of PYTHONHASHSEED help?
--
___
Python tracker
<https://bugs.python.org/issue44
Chris Jerdonek added the comment:
FYI, I tried myself, and setting PYTHONHASHSEED didn't make the failures
deterministic.
--
___
Python tracker
<https://bugs.python.org/is
Chris Jerdonek added the comment:
I agree with Serhiy that this API isn't necessarily the right one. It's just
what happens to be there now. Also, we're still not clear on our stance towards
cycles (see the issue25782 discussion). (Maybe the exposed version should
result in
Chris Jerdonek added the comment:
It might be good to have consistency with what will be used for StackSummary so
two different approaches to naming aren't used.
By the way, frame_sum is another possibility since I see frame_gen being used.
--
nosy: +chris.jer
Chris Jerdonek added the comment:
I was suggesting keeping more similarity between FrameSummary and StackSummary
in addition to differentiating frame from FrameSummary. Since stack is used for
StackSummary, frame_sum is more similar than f_summary while still providing
the differentiation
Chris Jerdonek added the comment:
Or frame_info (more readable), since FrameSummary is proposed to be
"Information about a single frame from a traceback."
--
___
Python tracker
<https://bugs.python.o
Chris Jerdonek added the comment:
> But, once the asyncio.Task is cancelled, is impossible to retrieve that
> original asyncio.CancelledError(msg) exception with the message, because it
> seems that *a new* asyncio.CancelledError() [without the message] is raised
> when asyncio
Chris Jerdonek added the comment:
> 2) Now: if I re-raise the asyncio.CancelledError as-is, I lose the message,
if I call the `asyncio.Task.exception()` function.
Re-raise asyncio.CancelledError where? (And what do you mean by "re-raise"?)
Call asyncio.Task.exception() where? Th
Chris Jerdonek added the comment:
I still don't see you calling asyncio.Task.exception() in your new attachment...
--
___
Python tracker
<https://bugs.python.org/is
Chris Jerdonek added the comment:
Here's a simplification of Marco's snippet to focus the discussion.
import asyncio
async def job():
# raise RuntimeError('error!')
await asyncio.sleep(5)
async def main():
task = asyncio.create_task(job())
a
Chris Jerdonek added the comment:
Since issue 38323 is still open, I think you should just comment on that
instead of creating a new issue.
--
nosy: +chris.jerdonek
___
Python tracker
<https://bugs.python.org/issue45
Change by Chris Jerdonek :
--
keywords: +patch
pull_requests: +19131
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/19811
___
Python tracker
<https://bugs.python.org/issu
Chris Jerdonek added the comment:
I made a naive attempt at addressing this issue here:
https://github.com/python/cpython/pull/19811
The code has diverged significantly since Nathaniel first linked to a specific
line above. However, what I came up with is simple, and seems to work. But I
Chris Jerdonek added the comment:
> Oh, no! Buildbot failures. Help?!
Yes, I'm sorry. There's something not so simple going on that I haven't yet
reproduced locally. Will reply on the tracker.
--
___
Python tracker
<ht
Change by Chris Jerdonek :
--
pull_requests: +19143
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/19823
___
Python tracker
<https://bugs.python.org/issu
Chris Jerdonek added the comment:
Okay, I was able to get the tests passing on the other platforms.
I'm still not sure why Mac and Fedora behaved differently with my original PR.
I was able to come up with a simple script that isolated the behavior
difference (posted in the PR com
New submission from Chris Jerdonek :
This issue is about how if a coroutine is wrapped in a Task with
asyncio.ensure_future(), then portions of the exception chain can be lost.
Specifically, if you run the following code, then ValueError will be raised
with exc.__context__ equal to the
Chris Jerdonek added the comment:
By the way, I just posted a new issue about exception chaining getting
suppressed, but this time in an asyncio setting with ensure_future():
https://bugs.python.org/issue40466
I first noticed this issue two or three years ago and raised it on the
async-sig
Chris Jerdonek added the comment:
New changeset 02047265eb83a43ba18cc7fee81756f1a1a1f968 by Chris Jerdonek in
branch 'master':
bpo-29587: Update gen.throw() to chain exceptions (#19823)
https://github.com/python/cpython/commit/02047265eb83a43ba18cc7fee81756
Chris Jerdonek added the comment:
Okay, thanks everyone. I think I'll take a look at issue 40466 next.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.pyth
Change by Chris Jerdonek :
--
keywords: +patch
pull_requests: +19174
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/19858
___
Python tracker
<https://bugs.python.org/issu
Change by Chris Jerdonek :
--
pull_requests: +19175
pull_request: https://github.com/python/cpython/pull/19859
___
Python tracker
<https://bugs.python.org/issue29
Chris Jerdonek added the comment:
FYI, I just created a PR to add one more test to the prior fix, to test a
slightly different aspect.
Whereas the test in the first PR checks that exc.__context__ is set after
gen.throw() is finished, the new test checks that exc.__context__ is available
Change by Chris Jerdonek :
--
nosy: +chris.jerdonek
___
Python tracker
<https://bugs.python.org/issue29590>
___
___
Python-bugs-list mailing list
Unsubscribe:
Chris Jerdonek added the comment:
My PR is ready for review: https://github.com/python/cpython/pull/19858
--
___
Python tracker
<https://bugs.python.org/issue40
Chris Jerdonek added the comment:
FYI, I was able to finish addressing the other exception-chaining cases (the
ones covered by the other issue) with a simple change to the fix for this PR.
I moved the call to _PyErr_ChainExceptions() a bit deeper: into gen_send_ex()
before the call to
Change by Chris Jerdonek :
--
pull_requests: +19189
pull_request: https://github.com/python/cpython/pull/19877
___
Python tracker
<https://bugs.python.org/issue29
Chris Jerdonek added the comment:
Okay, I was able to remove the NULL value check and get things working with a
NULL exception value. I just posted a second follow-on PR that does this (which
Guido approved - thanks, Guido!):
https://github.com/python/cpython/pull/19877
I wanted to tell you
Chris Jerdonek added the comment:
New changeset 21893fbb74e8fde2931fbed9b511e2a41362b1ab by Chris Jerdonek in
branch 'master':
bpo-29587: allow chaining NULL exceptions in _gen_throw() (GH-19877)
https://github.com/python/cpython/commit/21893fbb74e8fde2931fbed9b511e2
Change by Chris Jerdonek :
--
versions: +Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue29590>
___
___
Python-bugs-list mailin
Change by Chris Jerdonek :
--
keywords: +patch
pull_requests: +19207
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/19896
___
Python tracker
<https://bugs.python.org/issu
Chris Jerdonek added the comment:
I proposed a PR to fix this: https://github.com/python/cpython/pull/19896
--
___
Python tracker
<https://bugs.python.org/issue29
Chris Jerdonek added the comment:
Since none of you are subscribed to the other issue except for Nathaniel, I
thought I'd let you know I also posted a PR to fix another issue he filed
similar to this one (but this time about the stack trace being incorrect for
`gen.throw()` in ce
Change by Chris Jerdonek :
--
pull_requests: +19266
pull_request: https://github.com/python/cpython/pull/19858
___
Python tracker
<https://bugs.python.org/issue29
Chris Jerdonek added the comment:
Closing this as a duplicate of https://bugs.python.org/issue29587
It turns out that, as Nathaniel first suggested, this is really just another
special case of that issue (the "yield from" case as opposed to the "yield"
case). It's
Change by Chris Jerdonek :
--
keywords: +patch
pull_requests: +19267
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/19951
___
Python tracker
<https://bugs.python.org/issu
Chris Jerdonek added the comment:
I just posted a draft, proof-of-concept PR for one aspect of this issue:
https://github.com/python/cpython/pull/19951
Namely, the PR makes it so that cancelled tasks have full tracebacks, all the
way to where the code first gets interrupted. I did the C
Chris Jerdonek added the comment:
Okay, I completed my draft PR (both C and pure Python implementations are done).
--
___
Python tracker
<https://bugs.python.org/issue31
Change by Chris Jerdonek :
--
pull_requests: +19295
pull_request: https://github.com/python/cpython/pull/19979
___
Python tracker
<https://bugs.python.org/issue31
Chris Jerdonek added the comment:
I also posted a second PR (separate from the first) that adds a "msg" argument
to Future.cancel() and Task.cancel(). That PR is also now ready for review:
https://github.com/python/cpython/pull/19979
The other PR is simpler and more essential th
New submission from Chris Jerdonek :
There is a missing Py_DECREF in task_step_impl() in _asynciomodule.c:
https://github.com/python/cpython/blob/02fa0ea9c1073e4476c9bde3d7112f5dd964aa57/Modules/_asynciomodule.c#L2641
It should have the form:
if (clear_exc) {
Py_DECREF(exc
Chris Jerdonek added the comment:
Here is the original issue: https://bugs.python.org/issue31185
--
___
Python tracker
<https://bugs.python.org/issue40
Change by Chris Jerdonek :
--
keywords: +patch
pull_requests: +19306
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/19990
___
Python tracker
<https://bugs.python.org/issu
Chris Jerdonek added the comment:
FYI, there is a missing Py_DECREF from this change:
https://bugs.python.org/issue40559
(though it's an obscure code path as mentioned elsewhere in these comments)
--
nosy: +chris.jerdonek
___
Python tr
Chris Jerdonek added the comment:
New changeset d2c349b190bcba21a4a38e6520a48ad97a9f1529 by Chris Jerdonek in
branch 'master':
bpo-40559: Add Py_DECREF to _asynciomodule.c:task_step_impl() (GH-19990)
https://github.com/python/cpython/commit/d2c349b190bcba21a4a38e6520a48a
Chris Jerdonek added the comment:
New changeset 0e4a5e96f011989736bde824ab817146bd7c9cfc by Miss Islington (bot)
in branch '3.8':
[3.8] bpo-40559: Add Py_DECREF to _asynciomodule.c:task_step_impl() (GH-19990)
https://github.com/python/cpython/commit/0e4a5e96f011989736bde824ab8171
Chris Jerdonek added the comment:
New changeset 25014289887cb521c1041df4773c839d3fbf784e by Miss Islington (bot)
in branch '3.7':
[3.7] bpo-40559: Add Py_DECREF to _asynciomodule.c:task_step_impl() (GH-19990)
https://github.com/python/cpython/commit/25014289887cb521c1041df4773c83
Change by Chris Jerdonek :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Chris Jerdonek added the comment:
I looked into this a little after reproducing it locally.
What I found is that MultiLoopChildWatcher._sig_chld() *is* called. It's just
that it's only called immediately after timeout=5 has elapsed. (The timeout=5
was added by Andrew he
Chris Jerdonek added the comment:
I'm attaching a stand-alone script that can reproduce the issue. It doesn't use
unittest or even MultiLoopChildWatcher.
It starts an event loop and then repeatedly calls loop.subprocess_exec() with
0.2 seconds in between until the "hang&
Chris Jerdonek added the comment:
I'm attaching a slightly simpler version of the script.
--
Added file: https://bugs.python.org/file49145/test-kill2.py
___
Python tracker
<https://bugs.python.org/is
Chris Jerdonek added the comment:
I'm adding Nathaniel in case he can recognize this as one of the signal handler
cases he's already come across.
--
nosy: +njs
___
Python tracker
<https://bugs.python.o
Chris Jerdonek added the comment:
This looks like a duplicate of #38323: https://bugs.python.org/issue38323
--
nosy: +chris.jerdonek
___
Python tracker
<https://bugs.python.org/issue37
Chris Jerdonek added the comment:
> this seems like an awful lot of energy to spend on some code
that's not even used by default.
True, but it seems likely to me that this signals :) a deeper, more general
issue about CPython / signals (which is why I spent time on it). For exam
Chris Jerdonek added the comment:
I came up with the script by (1) running the test locally and seeing the same
hang, (2) moving the test function to its own script separate from the unit
tests and seeing the same hang, and (3) successively stripping away code while
continuing to check for
1 - 100 of 1575 matches
Mail list logo
