[issue45390] asyncio.Task doesn't propagate CancelledError() exception correctly.
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, but (2) without introducing two new intermediate CancelledErrors, which increase the verbosity of the traceback: Traceback (most recent call last): File "/home/andrew/projects/cpython/exc_traceback.py", line 14, in asyncio.run(main()) ^^^ File "/home/andrew/projects/cpython/Lib/asyncio/runners.py", line 44, in run return loop.run_until_complete(main) ^ File "/home/andrew/projects/cpython/Lib/asyncio/base_events.py", line 640, in run_until_complete return future.result() ^^^ File "/home/andrew/projects/cpython/exc_traceback.py", line 11, in main await task ^^ File "/home/andrew/projects/cpython/exc_traceback.py", line 5, in job await asyncio.sleep(5) ^^ File "/home/andrew/projects/cpython/Lib/asyncio/tasks.py", line 619, in sleep return await future asyncio.exceptions.CancelledError: cancel job (This is copied from Andrew's comment in the PR here: https://github.com/python/cpython/pull/31383#issuecomment-1046822899 ) Serhiy, can you provide a sample snippet for your case with output, like I did in my message linked above? -- ___ Python tracker <https://bugs.python.org/issue45390> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46829] Confusing CancelError message if multiple cancellations are scheduled
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 exception, in the same way that a normal exception's message can provide additional helpful context. Take for example this chunk of code: import asyncio import random async def job(): await asyncio.sleep(5) async def main(): task = asyncio.create_task(job()) await asyncio.sleep(1) r = random.random() if r < 0.5: task.cancel() else: task.cancel() await task if __name__=="__main__": asyncio.run(main()) Without passing a message, there's no way to tell which of the two lines called cancel, or why. The tracebacks are identical in both cases. This is even in the simplest case where only one cancellation is occurring. Passing a message lets one disambiguate the two call sites. And if there is truly a race condition where it's up in the air between two things cancelling it, I think it would be okay for the chosen message to be indeterminate, as either would have instigated the cancel in the absence of the other. -- ___ Python tracker <https://bugs.python.org/issue46829> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45390] asyncio.Task doesn't propagate CancelledError() exception correctly.
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 creation of intermediate exceptions. It would also cause is checks to work, which is what we want since behaviorally it should be the same exception. -- ___ Python tracker <https://bugs.python.org/issue45390> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46771] Add some form of cancel scopes
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 there truly is an implementation detail. It would be okay to document that the msg argument gets passed to the CancelledError via the constructor, as that was always the intent. See also issue 45390 and the message I wrote there on how to make that API work better (given that the msg is only available from the leaf exception in the exception chain, and the current implementation creates intermediate exceptions, I believe unnecessarily): https://bugs.python.org/issue45390#msg403570 -- ___ Python tracker <https://bugs.python.org/issue46771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46771] Add some form of cancel scopes
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.jerdonek ___ Python tracker <https://bugs.python.org/issue46771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45718] asyncio: MultiLoopWatcher has a race condition (Proposed work-around)
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/issue45718> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45390] asyncio.Task doesn't propagate CancelledError() exception correctly.
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())
await asyncio.sleep(1)
task.cancel('cancel job')
await task
if __name__=="__main__":
asyncio.run(main())
Running this pre-Python 3.9 gives something like this--
Traceback (most recent call last):
File "test.py", line 15, in
asyncio.run(main())
File "/.../python3.7/asyncio/runners.py", line 43, in run
return loop.run_until_complete(main)
File "/.../python3.7/asyncio/base_events.py", line 579, in run_until_complete
return future.result()
concurrent.futures._base.CancelledError
Running this with Python 3.9+ gives something like the following. The
difference is that the traceback now starts at the sleep() call:
Traceback (most recent call last):
File "/.../test.py", line 6, in job
await asyncio.sleep(5)
File "/.../python3.9/asyncio/tasks.py", line 654, in sleep
return await future
asyncio.exceptions.CancelledError: cancel job
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/.../test.py", line 12, in main
await task
asyncio.exceptions.CancelledError
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/.../test.py", line 15, in
asyncio.run(main())
File "/.../python3.9/asyncio/runners.py", line 44, in run
return loop.run_until_complete(main)
File "/.../python3.9/asyncio/base_events.py", line 642, in run_until_complete
return future.result()
asyncio.exceptions.CancelledError
Uncommenting the RuntimeError turns it into this--
Traceback (most recent call last):
File "/.../test.py", line 15, in
asyncio.run(main())
File "/.../python3.9/asyncio/runners.py", line 44, in run
return loop.run_until_complete(main)
File "/.../python3.9/asyncio/base_events.py", line 642, in run_until_complete
return future.result()
File "/.../test.py", line 12, in main
await task
File "/.../test.py", line 5, in job
raise RuntimeError('error!')
RuntimeError: error!
I agree it would be a lot nicer if the original CancelledError('cancel job')
could bubble up just like the RuntimeError does, instead of creating a new
CancelledError at each await and chaining it to the previous CancelledError.
asyncio's creation of a new CancelledError at each stage predates the PR that
added the chaining, so this could be viewed as an evolution of the change that
added the chaining.
I haven't checked to be sure, but the difference in behavior between
CancelledError and other exceptions might be explained by the following lines:
https://github.com/python/cpython/blob/3d1ca867ed0e3ae343166806f8ddd9739e568ab4/Lib/asyncio/tasks.py#L242-L250
You can see that for exceptions other than CancelledError, the exception is
propagated by calling super().set_exception(exc), whereas with CancelledError,
it is propagated by calling super().cancel() again.
Maybe this would even be an easy change to make. Instead of asyncio creating a
new CancelledError and chaining it to the previous, asyncio can just raise the
existing one. For the pure Python implementation at least, it may be as simple
as making a change here, inside _make_cancelled_error():
https://github.com/python/cpython/blob/3d1ca867ed0e3ae343166806f8ddd9739e568ab4/Lib/asyncio/futures.py#L135-L142
--
___
Python tracker
<https://bugs.python.org/issue45390>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45390] asyncio.Task doesn't propagate CancelledError() exception correctly.
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/issue45390> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45390] asyncio.Task doesn't propagate CancelledError() exception correctly.
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? This isn't part of your example, so it's not clear what you mean exactly. -- ___ Python tracker <https://bugs.python.org/issue45390> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45390] asyncio.Task doesn't propagate CancelledError() exception correctly.
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.Task.result() or asyncio.Task.exception() methods are called. You say it's "impossible", but isn't the message accessible via the exception chain (and visible in the traceback)? One benefit of not duplicating the message on the internal call to cancel() is that it makes it easier to pinpoint which CancelledError object is associated with the user's call to cancel(), and which is associated with the call done by asyncio internals, which is a different cancellation. Another benefit is that it prevents info from being duplicated in the traceback. -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue45390> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45075] confusion between frame and frame_summary in traceback module
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.org/issue45075> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45075] confusion between frame and frame_summary in traceback module
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. -- ___ Python tracker <https://bugs.python.org/issue45075> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45075] confusion between frame and frame_summary in traceback module
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.jerdonek ___ Python tracker <https://bugs.python.org/issue45075> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44938] Expose PyErr_ChainExceptions in the stable API
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 an error if it would cause a cycle to be created.) Someone would need to think through what the API should be, though. -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue44938> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44895] refleak test failure in test_exceptions
Chris Jerdonek added the comment: FYI, I tried myself, and setting PYTHONHASHSEED didn't make the failures deterministic. -- ___ Python tracker <https://bugs.python.org/issue44895> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44895] refleak test failure in test_exceptions
Chris Jerdonek added the comment: Last question: might trying different values of PYTHONHASHSEED help? -- ___ Python tracker <https://bugs.python.org/issue44895> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44895] refleak test failure in test_exceptions
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://bugs.python.org/issue44895> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44895] refleak test failure in test_exceptions
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 line later is too > late. How does this explain it not being non-deterministic on, say, macOS since the same lines of code will be executing each time? Is there a way to force things to happen in a deterministic fashion? (I interpreted the responses to mean that it's non-deterministic even when run on the same machine, so I'm not talking about, say, the differences from running macOS on different machines.) -- ___ Python tracker <https://bugs.python.org/issue44895> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44895] refleak test failure in test_exceptions
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 tracker <https://bugs.python.org/issue44895> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25782] CPython hangs on error __context__ set to the error itself
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. -- ___ Python tracker <https://bugs.python.org/issue25782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40696] Exception handling with "await" can hang in Python3.9.0b1
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 cause hangs (was "Exception handling with "await" can hang in Python3.9.0b1") -> Exception handling with "await" can hang in Python3.9.0b1 ___ Python tracker <https://bugs.python.org/issue40696> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25782] CPython hangs on error __context__ set to the error itself
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.python.org/issue25782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25782] CPython hangs on error __context__ set to the error itself
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 -> ... (leaving the cycle as is but just not hanging)? Is it not being changed then because the reasoning doesn't apply, or because we're restricted in what we can do by backwards compatibility? -- ___ Python tracker <https://bugs.python.org/issue25782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25782] CPython hangs on error __context__ set to the error itself
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 saying that example can't arise in the code path you're modifying? -- ___ Python tracker <https://bugs.python.org/issue25782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25782] CPython hangs on error __context__ set to the error itself
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 > ... -- ___ Python tracker <https://bugs.python.org/issue25782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25782] CPython hangs on error __context__ set to the error itself
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, too? -- ___ Python tracker <https://bugs.python.org/issue25782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38323] asyncio: MultiLoopWatcher has a race condition (test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x)
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, This is the conclusion I came to, too. But changing MultiLoopChildWatcher to use loop.add_signal_handler() would contradict the class's documented purpose and make it the same as SafeChildWatcher. This is why I think a maintainer needs to weigh in. The class's purpose / design might fundamentally not be workable. If it can't be made to work, maybe it should be removed or be documented as susceptible to hangs. -- ___ Python tracker <https://bugs.python.org/issue38323> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38323] asyncio: MultiLoopWatcher has a race condition (test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x)
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). The reason is that the hang is closely tied to MultiLoopChildWatcher's documented purpose. The only way I could see to fix MultiLoopChildWatcher would change its documented behavior and make it the same as SafeChildWatcher, which would defeat the purpose of having a separate class: https://github.com/python/cpython/pull/20142#issuecomment-712417912 Maybe there is a way to sidestep the hangs in the tests without fixing MultiLoopChildWatcher, but I didn't look into that. -- ___ Python tracker <https://bugs.python.org/issue38323> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44112] [buildbot] test_asyncio hangs (killed after 3 hours) on Refleak buildbots
Change by Chris Jerdonek : -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue44112> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43837] Operator precedence documentation could be more clear
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 context of newcomers to coding, it might be worth mentioning that parallel. Being able to connect to the familiar concepts of "first" and "last" might help people not familiar with precedence and binding. -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue43837> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37712] Exception frames from unittest.TestCase.fail dependent on nesting
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 gets fragmented across multiple locations. -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue37712> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31212] datetime: min date (0001-01-01 00:00:00) can't be converted to local timestamp
Change by Chris Jerdonek : -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue31212> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42140] asyncio.wait function creates futures set two times
Chris Jerdonek added the comment: If it's just a code cleanup and not a bugfix though, it shouldn't be backported. But yes, as a cleanup it's fine. And even if it's expected to go away later, it's okay to do now. -- ___ Python tracker <https://bugs.python.org/issue42140> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42140] asyncio.wait function creates futures set two times
Chris Jerdonek added the comment: Are you suggesting this is a bug, or is it just a suggested code cleanup? I ask because the docs suggest that a set should be passed: https://docs.python.org/3/library/asyncio-task.html#asyncio.wait And the docstring says it should be a sequence: https://github.com/python/cpython/blob/d1a0a960ee493262fb95a0f5b795b5b6d75cecb8/Lib/asyncio/tasks.py#L373-L376 So while code cleanup is okay, I'm not sure support for general iterator arguments can / should be guaranteed. -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue42140> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30181] Correct the parsing of a test case docstring.
Chris Jerdonek added the comment: I'm closing this as a duplicate of issue 39450, which has been resolved. -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> unittest TestCase shortDescription does not strip whitespace ___ Python tracker <https://bugs.python.org/issue30181> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37658] In some cases asyncio.wait_for can lead to socket leak.
Chris Jerdonek added the comment: Issue #42130 that was recently filed appears related to this change. -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue37658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42130] AsyncIO's wait_for can hide cancellation in a rare race condition
Chris Jerdonek added the comment: It looks like issue 37658 might be the relevant change rather. Here is the new logic it introduced: https://github.com/python/cpython/blob/db455296be5f792b8c12b7cd7f3962b52e4f44ee/Lib/asyncio/tasks.py#L483-L488 (via https://github.com/python/cpython/pull/21894 ) -- ___ Python tracker <https://bugs.python.org/issue42130> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42130] AsyncIO's wait_for can hide cancellation in a rare race condition
Change by Chris Jerdonek : -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue42130> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38323] asyncio: MultiLoopWatcher has a race condition (test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x)
Change by Chris Jerdonek : -- pull_requests: +21719 pull_request: https://github.com/python/cpython/pull/22756 ___ Python tracker <https://bugs.python.org/issue38323> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30181] Correct the parsing of a test case docstring.
Chris Jerdonek added the comment: I believe this was addressed by issue 39450, which I think was technically a duplicate of this issue. -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue30181> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39450] unittest TestCase shortDescription does not strip whitespace
Chris Jerdonek added the comment: I believe this also resolves issue 30181 (which was the same issue). -- nosy: +chris.jerdonek resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.8 ___ Python tracker <https://bugs.python.org/issue39450> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33647] Add str.replace(replacement_map)
Change by Chris Jerdonek : -- title: Add re.replace(string, replacement_map) -> Add str.replace(replacement_map) ___ Python tracker <https://bugs.python.org/issue33647> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33647] Add re.replace(string, replacement_map)
Chris Jerdonek added the comment: Another API option is to use str.replace's existing arguments: str.replace(old, new[, count]). In addition to "old" and "new" being strings, they could also be lists of strings of equal length, similar to how str.maketrans() can accept two strings of equal length. Then, like maketrans(), each string in "old" would be replaced by the corresponding string at the same position in "new." -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue33647> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40941] Merge generator.gi_running and frame executing flag into single frame state
Chris Jerdonek added the comment:
Mark, I want to flag issue29590 for you ("Incorrect stack traces when
re-entering a generator/coroutine stack via .throw()") in case this issue
relates to or would help at all with that.
--
nosy: +chris.jerdonek
___
Python tracker
<https://bugs.python.org/issue40941>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40932] subprocess docs should warn of shlex use on Windows
Change by Chris Jerdonek : -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue40932> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31213] __context__ reset to None in nested exception
Change by Chris Jerdonek : -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue31213> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40679] show class name in method invocation TypeError
Chris Jerdonek added the comment: Thanks a lot, Victor. -- ___ Python tracker <https://bugs.python.org/issue40679> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40222] "Zero cost" exception handling
Chris Jerdonek added the comment: To clarify, would there be any observable difference in behavior aside from speed? And would there be any limitations in when the speedup can be applied? -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue40222> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25782] CPython hangs on error __context__ set to the error itself
Chris Jerdonek added the comment: I think this issue needs deeper discussion to know how to proceed. > If there is a chain A -> B -> C -> D -> E, after assignment C.__context__ = A > we will get a chain C -> A -> B -> D -> E. No exception is lost. I understand not wanting to lose exceptions here. However, if there were a separate exception F and the assignment were instead C.__context__ = F without raising C, the new chain would be A -> B -> C -> F. We would again lose D -> E. So why is that not a problem here, and yet it's a problem above? If we really didn't want to lose the exception, we could make it A -> B -> C -> F -> D -> E (and if raising C, it would become C -> F -> D -> E). Thus, I think we may want to consider separately the cases of explicitly setting the context (calling PyException_SetContext) and implicitly setting it (calling PyErr_SetObject). Maybe when setting explicitly, losing the previous value is okay. Also, there's another option for the top example in the implicit case of raising C. We could create a copy C' of C, so the new chain would be C -> A -> B -> C' -> D -> E. The code already has logic to create a new exception in certain cases: both _PyErr_SetObject and _PyErr_NormalizeException call _PyErr_CreateException. There are yet more options but I don't want to lengthen this comment further. Lastly, regarding Dennis's patch, I think the question of how to detect cycles should be discussed separately from what the behavior should be. -- ___ Python tracker <https://bugs.python.org/issue25782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25782] CPython hangs on error __context__ set to the error itself
Change by Chris Jerdonek : -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue25782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40736] better message for re.search TypeError ("expected string or bytes-like object")
Chris Jerdonek added the comment: I already started one actually. But if I don't get to it in a week, I'll make a note here and you can take it up. -- ___ Python tracker <https://bugs.python.org/issue40736> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34852] Counter-intuitive behavior of Server.close() / wait_closed()
Change by Chris Jerdonek : -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue34852> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40743] [CMake] It's 2020, where is CMake?
Chris Jerdonek added the comment:
This was discussed a bit last December 2019 here ("Is there prior discussion
around the build system of CPython itself?"):
https://discuss.python.org/t/is-there-prior-discussion-around-the-build-system-of-cpython-itself/2813
--
nosy: +chris.jerdonek
___
Python tracker
<https://bugs.python.org/issue40743>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39343] Travis CI: documentation job fails in library/nntplib.rst with random network issue on news.gmane.io
Chris Jerdonek added the comment: Reopening as this is happening again -- twice for me: https://github.com/python/cpython/pull/20329/checks?check_run_id=701405252#step:7:117 -- nosy: +chris.jerdonek resolution: fixed -> status: closed -> open ___ Python tracker <https://bugs.python.org/issue39343> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23188] Provide a C helper function to chain raised (but not yet caught) exceptions
Chris Jerdonek added the comment: > The documentation of PyErr_SetObject, PyErr_SetString et al should also be > updated to mention exception chaining. I just posted a PR to do the above: https://github.com/python/cpython/pull/20329 -- ___ Python tracker <https://bugs.python.org/issue23188> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23188] Provide a C helper function to chain raised (but not yet caught) exceptions
Change by Chris Jerdonek : -- keywords: +patch pull_requests: +19597 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/20329 ___ Python tracker <https://bugs.python.org/issue23188> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23188] Provide a C helper function to chain raised (but not yet caught) exceptions
Chris Jerdonek added the comment: I just want to point out one difference between _PyErr_ChainExceptions and PyErr_SetObject that I encountered while working on this issue: https://bugs.python.org/issue40696 While both functions set the context, only PyErr_SetObject does a check to prevent cycles from forming in the context chain (albeit an incomplete check, which can lead to hangs, which I mention in the issue linked above). -- ___ Python tracker <https://bugs.python.org/issue23188> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40696] exception chain cycles cause hangs (was "Exception handling with "await" can hang in Python3.9.0b1")
Change by Chris Jerdonek : -- stage: patch review -> needs patch versions: +Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue40696> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40696] exception chain cycles cause hangs (was "Exception handling with "await" can hang in Python3.9.0b1")
Chris Jerdonek added the comment:
Good to hear, Mariusz! And thanks for the report!
Also, as discussed above, I'm leaving this issue open (and retitling) until the
following more general issue is fixed:
try:
raise RuntimeError
except Exception as exc:
print(f'handling: {exc!r}')
exc.__context__ = exc
raise ValueError # hangs
As I mentioned above, I believe this is because _PyErr_SetObject() only checks
for cycles that involve the exception being raised. In this case, the cycle
involves the exception one further down:
ValueError -> RuntimeError -> RuntimeError -> RuntimeError -> ...
--
title: Exception handling with "await" can hang in Python3.9.0b1 -> exception
chain cycles cause hangs (was "Exception handling with "await" can hang in
Python3.9.0b1")
___
Python tracker
<https://bugs.python.org/issue40696>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40696] Exception handling with "await" can hang in Python3.9.0b1
Chris Jerdonek added the comment: New changeset 7f77ac463cff219e0c8afef2611cad5080cc9df1 by Miss Islington (bot) in branch '3.9': bpo-40696: Fix a hang that can arise after gen.throw() (GH-20287) https://github.com/python/cpython/commit/7f77ac463cff219e0c8afef2611cad5080cc9df1 -- ___ Python tracker <https://bugs.python.org/issue40696> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40679] show class name in method invocation TypeError
Chris Jerdonek added the comment: > _PyObject_FunctionString as discussed here ( > https://bugs.python.org/issue37645 ) returns a string that also includes the > module name where applicable. By the way, Dennis, regarding the above, one thing I noticed is that Python doesn't currently expose a convenient way to get the fully qualified name of a class (the "full name" as opposed to the qualified name). It might be worth exploring what that would involve. I think it would be useful, personally. -- ___ Python tracker <https://bugs.python.org/issue40679> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19756] test_nntplib: sporadic failures, network isses? server down?
Change by Chris Jerdonek : -- nosy: -chris.jerdonek ___ Python tracker <https://bugs.python.org/issue19756> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19613] test_nntplib: sporadic failures, test_article_head_body()
Change by Chris Jerdonek : -- nosy: -chris.jerdonek ___ Python tracker <https://bugs.python.org/issue19613> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40736] better message for re.search TypeError ("expected string or bytes-like object")
New submission from Chris Jerdonek :
This TypeError could be a bit better:
"/Users/runner/runners/2.262.1/work/cpython/cpython/Lib/test/test_nntplib.py",
line 293, in test_with_statement
if re.search(r'(?i)KEY.TOO.SMALL', ssl_err.reason):
File "/Users/runner/runners/2.262.1/work/cpython/cpython/Lib/re.py", line
201, in search
return _compile(pattern, flags).search(string)
TypeError: expected string or bytes-like object
It just says "expected string or bytes-like object" but could include what type
it found.
--
components: Library (Lib)
messages: 369652
nosy: chris.jerdonek
priority: normal
severity: normal
status: open
title: better message for re.search TypeError ("expected string or bytes-like
object")
type: enhancement
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue40736>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19613] test_nntplib: sporadic failures, test_article_head_body()
Chris Jerdonek added the comment: See also: https://bugs.python.org/issue40735 (test_with_statement) -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue19613> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19756] test_nntplib: sporadic failures, network isses? server down?
Chris Jerdonek added the comment: See also: https://bugs.python.org/issue40735 (test_with_statement) -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue19756> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40735] test_nntplib: sporadic failures, NetworkedNNTP_SSLTests.test_with_statement
New submission from Chris Jerdonek : A sporadic failure of test_nntplib.NetworkedNNTP_SSLTests.test_with_statement on the CI for macOS: https://github.com/python/cpython/pull/20321/checks?check_run_id=700729471#step:6:612 See also: * https://bugs.python.org/issue19613 (test_article_head_body) * https://bugs.python.org/issue19756 (test_capabilities) ERROR: test_with_statement (test.test_nntplib.NetworkedNNTP_SSLTests) -- Traceback (most recent call last): File "/Users/runner/runners/2.262.1/work/cpython/cpython/Lib/test/test_nntplib.py", line 277, in test_with_statement server = self.NNTP_CLASS(self.NNTP_HOST, File "/Users/runner/runners/2.262.1/work/cpython/cpython/Lib/nntplib.py", line 1025, in __init__ super().__init__(host, port, user, password, readermode, File "/Users/runner/runners/2.262.1/work/cpython/cpython/Lib/nntplib.py", line 334, in __init__ self.sock = self._create_socket(timeout) File "/Users/runner/runners/2.262.1/work/cpython/cpython/Lib/nntplib.py", line 1031, in _create_socket sock = _encrypt_on(sock, self.ssl_context, self.host) File "/Users/runner/runners/2.262.1/work/cpython/cpython/Lib/nntplib.py", line 292, in _encrypt_on return context.wrap_socket(sock, server_hostname=hostname) File "/Users/runner/runners/2.262.1/work/cpython/cpython/Lib/ssl.py", line 500, in wrap_socket return self.sslsocket_class._create( File "/Users/runner/runners/2.262.1/work/cpython/cpython/Lib/ssl.py", line 1040, in _create self.do_handshake() File "/Users/runner/runners/2.262.1/work/cpython/cpython/Lib/ssl.py", line 1309, in do_handshake self._sslobj.do_handshake() ssl.SSLEOFError: EOF occurred in violation of protocol (_ssl.c:1097) During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/Users/runner/runners/2.262.1/work/cpython/cpython/Lib/test/test_nntplib.py", line 250, in wrapped meth(self) File "/Users/runner/runners/2.262.1/work/cpython/cpython/Lib/test/test_nntplib.py", line 293, in test_with_statement if re.search(r'(?i)KEY.TOO.SMALL', ssl_err.reason): File "/Users/runner/runners/2.262.1/work/cpython/cpython/Lib/re.py", line 201, in search return _compile(pattern, flags).search(string) TypeError: expected string or bytes-like object -- components: Tests messages: 369648 nosy: chris.jerdonek priority: normal severity: normal status: open title: test_nntplib: sporadic failures, NetworkedNNTP_SSLTests.test_with_statement type: behavior ___ Python tracker <https://bugs.python.org/issue40735> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40679] show class name in method invocation TypeError
Chris Jerdonek added the comment: Thanks again, Dennis! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue40679> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40679] show class name in method invocation TypeError
Chris Jerdonek added the comment: New changeset b5cc2089cc354469f12eabc7ba54280e85fdd6dc by Dennis Sweeney in branch 'master': bpo-40679: Use the function's qualname in certain TypeErrors (GH-20236) https://github.com/python/cpython/commit/b5cc2089cc354469f12eabc7ba54280e85fdd6dc -- ___ Python tracker <https://bugs.python.org/issue40679> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40696] Exception handling with "await" can hang in Python3.9.0b1
Chris Jerdonek added the comment: New changeset 7c30d12bd5359b0f66c4fbc98aa055398bcc8a7e by Chris Jerdonek in branch 'master': bpo-40696: Fix a hang that can arise after gen.throw() (GH-20287) https://github.com/python/cpython/commit/7c30d12bd5359b0f66c4fbc98aa055398bcc8a7e -- ___ Python tracker <https://bugs.python.org/issue40696> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40690] unittest: if FunctionTestCase is imported, the loader loads "tests" from it
Chris Jerdonek added the comment: > then you will have 1 extra test in that module (the imported one), moreover, > that test will be broken. If this is true, then how is anyone able to be using FunctionTestCase in their tests today? Is the feature broken? -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue40690> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40696] Exception handling with "await" can hang in Python3.9.0b1
Chris Jerdonek added the comment: Mariusz, someone may also want to review Django's code there. Raising an exception that would otherwise create a cycle in the chain could be obscuring another issue, or there could be more straightforward alternatives. (The Python issue will still be fixed of course.) -- ___ Python tracker <https://bugs.python.org/issue40696> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23188] Provide a C helper function to chain raised (but not yet caught) exceptions
Change by Chris Jerdonek : -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue23188> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40679] show class name in method invocation TypeError
Change by Chris Jerdonek : -- components: +Interpreter Core versions: +Python 3.10 -Python 3.9 ___ Python tracker <https://bugs.python.org/issue40679> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40696] Exception handling with "await" can hang in Python3.9.0b1
Change by Chris Jerdonek : -- components: +Interpreter Core -asyncio title: "await" hangs in Python3.9.0b1. -> Exception handling with "await" can hang in Python3.9.0b1 type: -> behavior versions: +Python 3.10 ___ Python tracker <https://bugs.python.org/issue40696> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40696] "await" hangs in Python3.9.0b1.
Chris Jerdonek added the comment: Also, I just want to point out one thing about _PyErr_SetObject(). I believe it can detect cycles of arbitrary length (which is what the while loop is for). It's just that it can only detect cycles that involve the first node. So for things to fail with _PyErr_SetObject(), someone would need to mess with exceptions further down the chain. So I *think* hangs should be pretty unlikely with the narrower fix. -- ___ Python tracker <https://bugs.python.org/issue40696> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40696] "await" hangs in Python3.9.0b1.
Chris Jerdonek added the comment: I just posted a draft PR that implements the narrower fix: https://github.com/python/cpython/pull/20287 I confirmed that the Django test passes with it. I also included two regression tests: one using only generators, and one more like the Django test that awaits a task. My solution was to update the exception context in gen_send_ex() using _PyErr_SetObject() instead of _PyErr_ChainExceptions() -- because _PyErr_SetObject() does the cycle detection we've been discussing, and _PyErr_ChainExceptions() doesn't. While _PyErr_SetObject()'s cycle detection isn't complete in that it can't detect cycles that begin further down the chain, it's good enough for this case. -- ___ Python tracker <https://bugs.python.org/issue40696> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40696] "await" hangs in Python3.9.0b1.
Change by Chris Jerdonek : -- keywords: +patch pull_requests: +19561 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20287 ___ Python tracker <https://bugs.python.org/issue40696> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40706] Unreachable code in _PyEval_EvalCode
Change by Chris Jerdonek : -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue40706> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40679] show class name in method invocation TypeError
Chris Jerdonek added the comment: > So maybe the test coverage (or removal?) should be a separate issue. That sounds good. Want to file the issue? -- ___ Python tracker <https://bugs.python.org/issue40679> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40696] "await" hangs in Python3.9.0b1.
Chris Jerdonek added the comment: Okay, I'll keep it one issue then. Someone else is still welcome to work on the more general issue. Note that there is some chance the narrower fix should happen independent of the more general fix. This is because _PyErr_ChainExceptions() (which is the call I added for the gen.throw() case) doesn't call the code path that we're discussing. Thus, cycles could still wind up being introduced at that call site. -- ___ Python tracker <https://bugs.python.org/issue40696> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40696] "await" hangs in Python3.9.0b1.
Chris Jerdonek added the comment: >From a process perspective, I think we should probably pursue two PR's for >this: one for the general issue that affects all Python versions (what Yury is >talking about), and something narrower that addresses the 3.9.0b1 case that >came up here. I'd like to focus on the latter first. Someone else is welcome >to work on the more general issue while I'm doing that. I'm not 100% sure if the more general issue should be a new bpo issue or not. I'm leaning towards separate because it is bigger and there are different decisions to be made around backporting, etc, but we should decide that now. If someone else agrees, I can create a new issue. -- ___ Python tracker <https://bugs.python.org/issue40696> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40696] "await" hangs in Python3.9.0b1.
Chris Jerdonek added the comment:
I don't think that would be a real solution because it looks like that would
cause the while loop always to loop at most once (which would defeat its
purpose) -- because the loop ends with "o = context":
while ((context = PyException_GetContext(o))) {
Py_DECREF(context);
if (context == value) {
PyException_SetContext(o, NULL);
break;
}
o = context;
}
--
___
Python tracker
<https://bugs.python.org/issue40696>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40696] "await" hangs in Python3.9.0b1.
Chris Jerdonek added the comment: The Django details might not matter so much at this point, but to add to something I said above: It might not only be process_exception_by_middleware() as I mentioned, but also asgiref's sync_to_async() function. In that function, you can see an already active exception being re-raised (here the exc_info comes from sys.exc_info()): # If we have an exception, run the function inside the except block # after raising it so exc_info is correctly populated. if exc_info[1]: try: raise exc_info[1] except: return func(*args, **kwargs) else: return func(*args, **kwargs) https://github.com/django/asgiref/blob/edd0570a4f6e46f0948afa5ef197a192bb95b7b7/asgiref/sync.py#L306-L314 -- ___ Python tracker <https://bugs.python.org/issue40696> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40696] "await" hangs in Python3.9.0b1.
Chris Jerdonek added the comment: To start out sharing what I found in the Django code: Here inside BaseHandler._get_response_async(): https://github.com/django/django/blob/3460ea49e839fd6bb924c48eaa1cd3d6dc888035/django/core/handlers/base.py#L226-L232 try: response = await wrapped_callback(request, *callback_args, **callback_kwargs) except Exception as e: response = await sync_to_async( # This line hangs. self.process_exception_by_middleware, thread_sensitive=True, )(e, request) you can see an exception being handled, which is then passed to process_exception_by_middleware(). Process_exception_by_middleware() can wind up re-raising that same exception, which causes __context__ to be set circularly inside the except block: https://github.com/django/django/blob/3460ea49e839fd6bb924c48eaa1cd3d6dc888035/django/core/handlers/base.py#L323-L332 If you boil this down, you get the following as a simple reproducer. This doesn't hang, but you can tell the difference by comparing exc2 to exc2.__context as indicated below: import asyncio async def process_exc(exc): raise exc async def run(): try: raise RuntimeError except Exception as exc: task = asyncio.create_task(process_exc(exc)) try: await task except BaseException as exc2: # Prints True in 3.9.0b1 and False in 3.9.0a6. print(exc2 is exc2.__context__) loop = asyncio.new_event_loop() try: loop.run_until_complete(run()) finally: loop.close() The cause is probably the following PR, which enabled exception chaining for gen.throw() in the yield from case: https://github.com/python/cpython/pull/19858 So the answer might be to do some cycle detection when chaining the exception, which apparently _PyErr_ChainExceptions() doesn't do. -- ___ Python tracker <https://bugs.python.org/issue40696> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40696] "await" hangs in Python3.9.0b1.
Chris Jerdonek added the comment:
FWIW, I found that the following hangs, but it also hangs on earlier versions
of Python:
import traceback
try:
raise RuntimeError
except Exception as exc:
print(f'handling: {exc!r}')
exc.__context__ = exc
print('printing traceback')
print(traceback.format_exc()) # hangs
Is this a separate bug? So maybe the issue is that the new code is letting
things get into this state. Some of my changes added new chaining in various
places, so that would fit (but still investigating).
--
___
Python tracker
<https://bugs.python.org/issue40696>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40696] "await" hangs in Python3.9.0b1.
Chris Jerdonek added the comment: I'm getting close to tracking this down. There is a certain point in the code path of the Django test where `exc is exc.__context__` becomes True. I'm guessing this is what's causing the hang. I'll try to get a simple reproducer (there is a lot of Django code to sort through). -- ___ Python tracker <https://bugs.python.org/issue40696> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40696] "await" hangs in Python3.9.0b1.
Change by Chris Jerdonek : -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue40696> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40679] show class name in method invocation TypeError
Chris Jerdonek added the comment: Oh, that string is used in even more spots (sorry wasn't looking too closely the first time). -- ___ Python tracker <https://bugs.python.org/issue40679> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40679] show class name in method invocation TypeError
Chris Jerdonek added the comment: Oh, I see now I was hitting a different line: https://github.com/python/cpython/blob/master/Objects/call.c#L1009 Maybe my suggestion is enough to help you (I didn't really look closely at the code), or maybe you were already aware of that. -- ___ Python tracker <https://bugs.python.org/issue40679> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40679] show class name in method invocation TypeError
Chris Jerdonek added the comment:
> Or should we be satisfied with the half-measure of including the qualname but
> not the module (at least for now)?
This is something I was wondering myself, too (also for other contexts). Let's
take things one step at a time and limit ourselves just to __qualname__ in this
issue. Including the module name can be discussed in a separate issue. (This
question also comes up for the __repr__ of objects -- sometimes it includes the
fully qualified name and sometimes it doesn't.)
For your last question, does this work?
>>> def foo(**kwargs): pass
...
>>> foo(**{1: 2})
Traceback (most recent call last):
File "", line 1, in
TypeError: keywords must be strings
(Also, the corrected link is here:
https://github.com/python/cpython/blob/master/Python/ceval.c#L4182 )
--
___
Python tracker
<https://bugs.python.org/issue40679>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29590] Incorrect stack traces when re-entering a generator/coroutine stack via .throw()
Chris Jerdonek added the comment: I just filed a related issue to this that's also similar to issue 29587: https://bugs.python.org/issue40694 -- ___ Python tracker <https://bugs.python.org/issue29590> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40694] gen.throw() with multiple yield froms skips intermediate exceptions
New submission from Chris Jerdonek :
Here is another gen.throw() exception chain example similar to the examples in
issue 29587: https://bugs.python.org/issue29587
def f():
yield
def g():
try:
raise RuntimeError('a')
except Exception as exc:
print(f'handling: {exc!r}')
yield from f()
def h():
try:
raise RuntimeError('b')
except Exception as exc:
print(f'handling: {exc!r}')
yield from g()
gen = h()
gen.send(None)
gen.throw(ValueError)
Output:
handling: RuntimeError('b')
handling: RuntimeError('a')
Traceback (most recent call last):
File "/.../test.py", line 13, in h
raise RuntimeError('b')
RuntimeError: b
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/.../test.py", line 20, in
gen.throw(ValueError)
File "/.../test.py", line 16, in h
yield from g()
File "/.../test.py", line 9, in g
yield from f()
File "/.../test.py", line 2, in f
yield
ValueError
The issue is that "RuntimeError: a" is skipped. It should also appear in the
exception chain.
I believe this has the same root cause as issue 29590:
https://bugs.python.org/issue29590
--
components: Interpreter Core
messages: 369416
nosy: chris.jerdonek
priority: normal
severity: normal
status: open
title: gen.throw() with multiple yield froms skips intermediate exceptions
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue40694>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40679] show class name in method invocation TypeError
Chris Jerdonek added the comment: Thanks! I think it does. Also, I see now that using the __qualname__ is better than including the object's type for locating the method because you can have cases like super().foo() or even-- class A: def foo(self): pass def bar(): pass A.foo = bar -- ___ Python tracker <https://bugs.python.org/issue40679> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40124] Clearer assertion error
Chris Jerdonek added the comment: How about we review Phil's PR, which adds a message to the assertion. And then we can keep this issue open to discuss converting the assertion to an exception. I think Phil's PR is an improvement. -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue40124> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39976] Add "**other_popen_kwargs" to subprocess API signatures in docs
Chris Jerdonek added the comment: New changeset 05525fff8a46f4d479cc029e4ea57b35b153f015 by Miss Islington (bot) in branch '3.7': bpo-39976: Add **other_popen_kwargs to subprocess docs (GH-20145) https://github.com/python/cpython/commit/05525fff8a46f4d479cc029e4ea57b35b153f015 -- ___ Python tracker <https://bugs.python.org/issue39976> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39976] Add "**other_popen_kwargs" to subprocess API signatures in docs
Chris Jerdonek added the comment: New changeset 257e11cebde6b29177a206abd1e395367799ed42 by Miss Islington (bot) in branch '3.8': bpo-39976: Add **other_popen_kwargs to subprocess docs (GH-20145) https://github.com/python/cpython/commit/257e11cebde6b29177a206abd1e395367799ed42 -- ___ Python tracker <https://bugs.python.org/issue39976> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40679] show class name in method invocation TypeError
New submission from Chris Jerdonek : When calling an instance method incorrectly, you will often get a TypeError that is some variation of the following: Traceback (most recent call last): File "/.../test.py", line 6, in a.foo(1) TypeError: foo() takes 1 positional argument but 2 were given However, when multiple classes have method foo() and the type of "a" isn't immediately obvious, this often isn't enough to know what method was being called. Thus, it would be more helpful if the error message includes also the class that foo() belongs to, or alternatively the type of the object. (These can be different when subclasses are involved.) For comparison, if you call a method that doesn't exist, you will get a message that looks like the following: Traceback (most recent call last): File "/.../test.py", line 6, in a.bar(1) AttributeError: 'A' object has no attribute 'bar' So taking from this as an example, the message in the first case could be something like-- TypeError: foo() for 'A' object takes 1 positional argument but 2 were given -- messages: 369324 nosy: chris.jerdonek priority: normal severity: normal status: open title: show class name in method invocation TypeError type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue40679> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38306] High level API for loop.run_in_executor(None, ...)?
Chris Jerdonek added the comment: Is this issue the same as this one? https://bugs.python.org/issue32309 -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue38306> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36456] task.cancel unbound recursion
Change by Chris Jerdonek : -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue36456> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
