[issue39060] asyncio.Task.print_stack doesn't print the full stack

Change by Chris Jerdonek : -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue39060> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39839] Non-working error handler when creating a task with assigning a variable

Chris Jerdonek added the comment: I took a look at this. Basically, the reason the exception handler isn't firing when the task is still in scope is that the exception handler is only a handler of "last resort." You can see that the exception handler is called inside Task.__

[issue39839] Non-working error handler when creating a task with assigning a variable

Change by Chris Jerdonek : -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue39839> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40672] asyncio.wait_for: process future result produced during cancelation

Chris Jerdonek added the comment: Regarding the documentation, I'm not sure we _need_ to say what happens in this edge case for 3.9. It was already unspecified before 3.9, so we're not any worse off. (The change in issue 40607 was, however, documented.) I'd rather come to agreement on (1

[issue31033] Improve traceback of cancelled tasks / add cancel() msg argument

Chris Jerdonek added the comment: New changeset ff7a8b03c49153021d6de5d0b2fa8b5163059ed6 by Chris Jerdonek in branch 'master': Use _PyErr_ChainStackItem() inside gen_send_ex(). (GH-20173) https://github.com/python/cpython/commit/ff7a8b03c49153021d6de5d0b2fa8b5163059ed6

[issue31033] Improve traceback of cancelled tasks / add cancel() msg argument

Change by Chris Jerdonek : -- pull_requests: +19472 pull_request: https://github.com/python/cpython/pull/20173 ___ Python tracker <https://bugs.python.org/issue31

[issue40607] asyncio.wait_for should reraise future exception even if timeout expires

Chris Jerdonek added the comment: Thank you again, Roman and all. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.9 -Python 3.8 ___ Python tracker <https://bugs.python.or

[issue31131] asyncio.wait_for() TimeoutError doesn't provide full traceback

Chris Jerdonek added the comment: This issue was just resolved by the combination of #40607 followed by #31033 (merged for 3.9.0 beta 1). Running the example code above now results in the following: Traceback (most recent call last): File "/.../cpython/test-31131.py", line

[issue31033] Improve traceback of cancelled tasks / add cancel() msg argument

Chris Jerdonek added the comment: Thanks so much, Yury. (Removing the "release blocker" flag now that it has been merged.) -- priority: release blocker -> normal resolution: -> fixed stage: patch review -> resolved status: open -> closed title: Add argumen

[issue31033] Add argument to .cancel() of Task and Future

Chris Jerdonek added the comment: New changeset da742ba826721da84140abc785856d4ccc2d787f by Chris Jerdonek in branch 'master': bpo-31033: Improve the traceback for cancelled asyncio tasks (GH-19951) https://github.com/python/cpython/commit/da742ba826721da84140abc785856d4ccc2d787f

[issue40152] Coroutine hangs if it performs async operations when handling exception sent using throw()

Change by Chris Jerdonek : -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue40152> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39976] Add "**other_popen_kwargs" to subprocess API signatures in docs

Chris Jerdonek added the comment: I'm not sure if this is worth backporting, but let me know if you think it should. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bug

[issue39976] Add "**other_popen_kwargs" to subprocess API signatures in docs

Chris Jerdonek added the comment: New changeset 46545000c2a30b46aed717b546bc09e5bae7148f by Zackery Spytz in branch 'master': bpo-39976: Add **other_popen_kwargs to subprocess docs (GH-20145) https://github.com/python/cpython/commit/46545000c2a30b46aed717b546bc09e5bae7148f -- nosy

[issue29587] Generator/coroutine 'throw' discards exc_info state, which is bad

Chris Jerdonek added the comment: New changeset d7184d3dbd249444ec3961641dc08a9ad3c1ac34 by Chris Jerdonek in branch 'master': bpo-29587: Add another test for the gen.throw() fix. (GH-19859) https://github.com/python/cpython/commit/d7184d3dbd249444ec3961641dc08a9ad3c1ac34

[issue38323] asyncio: MultiLoopWatcher has a race condition (test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x)

Change by Chris Jerdonek : -- type: -> behavior ___ Python tracker <https://bugs.python.org/issue38323> ___ ___ Python-bugs-list mailing list Unsubscrib

[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: I posted a draft PR for this issue: https://github.com/python/cpython/pull/20142 -- ___ Python tracker <https://bugs.python.org/issue38

[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: +19447 pull_request: https://github.com/python/cpython/pull/20142 ___ Python tracker <https://bugs.python.org/issue38

[issue32309] Implement asyncio.run_in_executor shortcut

Change by Chris Jerdonek : -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue32309> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue31033] Add argument to .cancel() of Task and Future

Chris Jerdonek added the comment: I just want to flag one issue after rebasing my traceback PR onto what was merged. If task.cancel() is called like this-- task.cancel("POSSIBLY LONG CANCEL MESSAGE") There is the question of whether the passed message should be repeated

[issue31033] Add argument to .cancel() of Task and Future

Chris Jerdonek added the comment: The msg argument has now been added (second PR). I'm going to keep this issue open until the traceback issue has also been addressed (the other PR), as that was one part of the discussions here. -- ___ Python

[issue31033] Add argument to .cancel() of Task and Future

Chris Jerdonek added the comment: New changeset 1ce5841eca6d96b1b1e8c213d04f2e92b1619bb5 by Chris Jerdonek in branch 'master': bpo-31033: Add a msg argument to Future.cancel() and Task.cancel() (GH-19979) https://github.com/python/cpython/commit/1ce5841eca6d96b1b1e8c213d04f2e92b1619bb5

[issue29587] Generator/coroutine 'throw' discards exc_info state, which is bad

Chris Jerdonek added the comment: New changeset 75cd8e48c62c97fdb9d9a94fd2335be06084471d by Chris Jerdonek in branch 'master': bpo-29587: Make gen.throw() chain exceptions with yield from (GH-19858) https://github.com/python/cpython/commit/75cd8e48c62c97fdb9d9a94fd2335be06084471d

[issue40615] unstable behaviour for options in argparse

Chris Jerdonek added the comment: One thing that's interesting is that you don't get the "ambiguous option" error if what's provided is an exact match (even if a prefix of both). For example, if you instead parsed "--clea", it would give the error: > error: ambiguo

[issue40615] unstable behaviour for options in argparse

Chris Jerdonek added the comment: Do you know about this section of the docs? https://docs.python.org/3/library/argparse.html#argument-abbreviations-prefix-matching -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue40

[issue40607] asyncio.wait_for should reraise future exception even if timeout expires

Chris Jerdonek added the comment: Also adding Nathaniel since he's the one that filed #32751. Nathaniel, do you agree that if an exception occurs while waiting for the cancellation, the exception should be what's raised instead of TimeoutError? -- nosy: +chris.jerdonek, njs

[issue37573] asyncio: freeze when using MultiLoopChildWatcher on Solaris

Change by Chris Jerdonek : -- resolution: -> duplicate ___ Python tracker <https://bugs.python.org/issue37573> ___ ___ Python-bugs-list mailing list Un

[issue37573] asyncio: freeze when using MultiLoopChildWatcher on Solaris

Chris Jerdonek added the comment: Closing as a duplicate of #38323: https://bugs.python.org/issue38323 -- stage: -> resolved status: open -> closed superseder: -> asyncio: MultiLoopWatcher has a race condition (test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 R

[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: I think I have a possible explanation for this now. In my reproducer script and in the original test, the wakeup file descriptor isn't set. I think this explains why the loop isn't waking up to call SIGCHLD's handler when the signal comes in. The reason

[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: I was able to simplify the script a lot more and continue to reproduce the hang. It's attached as test-kill3.py (80 lines). It doesn't use subprocess_exec() or a watcher anymore -- just subprocess.Popen() followed by popen.kill(), and then awaiting

[issue29587] Generator/coroutine 'throw' discards exc_info state, which is bad

Chris Jerdonek added the comment: Would someone be able to approve / take a look at this small PR addressing another aspect of this issue? https://github.com/python/cpython/pull/19858 I'm hoping it can be part of 3.9, and the deadline is just a week away. It builds on the already merged PR

[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: > 4. use call_later() to terminate the future after 5 seconds You should read that as "3.5" (I inserted it later). -- ___ Python tracker <https://bugs.pytho

[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: 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

[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 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 example,

[issue37573] asyncio: freeze when using MultiLoopChildWatcher on Solaris

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

[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: 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.org/issue38

[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: 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/issue38

[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: 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" happ

[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: 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 here: https

[issue40559] Missing Py_DECREF in task_step_impl() in _asynciomodule.c

Change by Chris Jerdonek : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue40559] Missing Py_DECREF in task_step_impl() in _asynciomodule.c

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/25014289887cb521c1041df4773c839d3fbf784e

[issue40559] Missing Py_DECREF in task_step_impl() in _asynciomodule.c

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/0e4a5e96f011989736bde824ab817146bd7c9cfc

[issue40559] Missing Py_DECREF in task_step_impl() in _asynciomodule.c

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/d2c349b190bcba21a4a38e6520a48ad97a9f1529

[issue31185] Miscellaneous errors in asyncio speedup module

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 tracker

[issue40559] Missing Py_DECREF in task_step_impl() in _asynciomodule.c

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

[issue40559] Missing Py_DECREF in task_step_impl() in _asynciomodule.c

Chris Jerdonek added the comment: Here is the original issue: https://bugs.python.org/issue31185 -- ___ Python tracker <https://bugs.python.org/issue40

[issue40559] Missing Py_DECREF in task_step_impl() in _asynciomodule.c

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

[issue31033] Add argument to .cancel() of Task and Future

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

[issue31033] Add argument to .cancel() of Task and Future

Change by Chris Jerdonek : -- pull_requests: +19295 pull_request: https://github.com/python/cpython/pull/19979 ___ Python tracker <https://bugs.python.org/issue31

[issue31033] Add argument to .cancel() of Task and Future

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

[issue31033] Add argument to .cancel() of Task and Future

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

[issue31033] Add argument to .cancel() of Task and Future

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

[issue40466] asyncio.ensure_future() breaks implicit exception chaining

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 just

[issue29587] Generator/coroutine 'throw' discards exc_info state, which is bad

Change by Chris Jerdonek : -- pull_requests: +19266 pull_request: https://github.com/python/cpython/pull/19858 ___ Python tracker <https://bugs.python.org/issue29

[issue29587] Generator/coroutine 'throw' discards exc_info state, which is bad

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 certain

[issue29590] Incorrect stack traces when re-entering a generator/coroutine stack via .throw()

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

[issue29590] Incorrect stack traces when re-entering a generator/coroutine stack via .throw()

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

[issue29590] Incorrect stack traces when re-entering a generator/coroutine stack via .throw()

Change by Chris Jerdonek : -- versions: +Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue29590> ___ ___ Python-bugs-list mailin

[issue29587] Generator/coroutine 'throw' discards exc_info state, which is bad

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/21893fbb74e8fde2931fbed9b511e2a41362b1ab

[issue29587] Generator/coroutine 'throw' discards exc_info state, which is bad

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

[issue29587] Generator/coroutine 'throw' discards exc_info state, which is bad

Change by Chris Jerdonek : -- pull_requests: +19189 pull_request: https://github.com/python/cpython/pull/19877 ___ Python tracker <https://bugs.python.org/issue29

[issue29587] Generator/coroutine 'throw' discards exc_info state, which is bad

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

[issue40466] asyncio.ensure_future() breaks implicit exception chaining

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

[issue29590] Incorrect stack traces when re-entering a generator/coroutine stack via .throw()

Change by Chris Jerdonek : -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue29590> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue29587] Generator/coroutine 'throw' discards exc_info state, which is bad

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

[issue29587] Generator/coroutine 'throw' discards exc_info state, which is bad

Change by Chris Jerdonek : -- pull_requests: +19175 pull_request: https://github.com/python/cpython/pull/19859 ___ Python tracker <https://bugs.python.org/issue29

[issue40466] asyncio.ensure_future() breaks implicit exception chaining

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

[issue29587] Generator/coroutine 'throw' discards exc_info state, which is bad

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.python.or

[issue29587] Generator/coroutine 'throw' discards exc_info state, which is bad

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/02047265eb83a43ba18cc7fee81756f1a1a1f968

[issue29587] Generator/coroutine 'throw' discards exc_info state, which is bad

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

[issue40466] asyncio.ensure_future() breaks implicit exception chaining

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

[issue29587] Generator/coroutine 'throw' discards exc_info state, which is bad

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 comments

[issue29587] Generator/coroutine 'throw' discards exc_info state, which is bad

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

[issue29587] Generator/coroutine 'throw' discards exc_info state, which is bad

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 <https://bugs.pyth

[issue29587] Generator/coroutine 'throw' discards exc_info state, which is bad

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

[issue29587] Generator/coroutine 'throw' discards exc_info state, which is bad

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

[issue37700] shutil.copyfile does not raise SpecialFileError for socket files

Chris Jerdonek added the comment: This issue is being filed after coming up in pip's tracker here (in a comment by Guido): https://github.com/pypa/pip/issues/5306#issuecomment-383355379 -- nosy: +chris.jerdonek ___ Python tracker <ht

[issue32528] Change base class for futures.CancelledError

Change by Chris Jerdonek : -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue32528> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32363] Deprecate task.set_result() and task.set_exception()

Chris Jerdonek added the comment: To stop the discussion from happening in two places (sorry, Yury), I started a broader discussion on Async-sig with thread starting here: https://mail.python.org/pipermail/async-sig/2019-February/000548.html

[issue32363] Deprecate task.set_result() and task.set_exception()

Chris Jerdonek added the comment: > Well, if you want to unconditionally end tasks you shouldn't write coroutines > that ignore CancelledErrors. Well, of course. But code can have bugs, and maybe you didn't write the coroutine because it's from a library that you don't control. In tha

[issue32363] Deprecate task.set_result() and task.set_exception()

Chris Jerdonek added the comment: > There's no clear reason to complicate the Task<->coroutine relationship by > allowing to inject arbitrary exceptions into running coroutines. My comment was more about CancelledError rather than arbitrary exceptions. You didn't reply to th

[issue32363] Deprecate task.set_result() and task.set_exception()

Chris Jerdonek added the comment: A second reason why Task.cancel() seems to be an incomplete replacement: Task.set_exception() and Task.set_result() both give you a way to unconditionally end a task. With cancel() though, the docs say, "Task.cancel() does not guarantee that the

[issue32363] Deprecate task.set_result() and task.set_exception()

Chris Jerdonek added the comment: Correction: that should have been bpo-31033. -- ___ Python tracker <https://bugs.python.org/issue32363> ___ ___ Python-bug

[issue32363] Deprecate task.set_result() and task.set_exception()

Chris Jerdonek added the comment: > Use Task.cancel() or use a Queue to communicate with the task. One reason why Task.cancel() is an incomplete replacement for Task.set_exception() is that you don't have an easy way to communicate why the task was ended. With set_except

[issue35951] os.renames() creates directories if original name doesn't exist

Chris Jerdonek added the comment: > And since it seems that it can not be solved completely, You may be right only to document, but you didn't note any problems with the possibility I suggested. A cleanup pruning step could be done on failure that is similar to the cleanup pruning s

[issue34028] Python 3.7.0 wont compile with SSL Support 1.1.0 > alledged missing X509_VERIFY_PARAM_set1_host() support

Change by Chris Jerdonek : -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue34028> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35951] os.renames() creates directories if original name doesn't exist

Chris Jerdonek added the comment: > As such the cleanup in case of failure should not be expected, Given that the documentation specifically calls out permissions errors as a cause of leaving the new directory in place, it wouldn't be unreasonable for someone to think the function d

[issue35955] difflib reports incorrect location of mismatch

Chris Jerdonek added the comment: Is this a duplicate of issue24780? -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue35955> ___ ___

[issue35951] os.renames() creates directories if original name doesn't exist

Chris Jerdonek added the comment: Lacking permissions seems very different to me from the source directory or file not existing. For example, in the example I provided, I did have the needed permissions. Incidentally (and this is a separate documentation issue), the note seems unclear

[issue35951] os.renames() creates directories if original name doesn't exist

New submission from Chris Jerdonek : os.renames() creates and leaves behind the intermediate directories if the original (source) path doesn't exist. >>> import os >>> os.mkdir('temp') >>> os.mkdir('temp/test') >>> os.renames('temp/not-exists', 'temp/test2/

[issue35821] Clarify when logging events are propagated when propagate is true

Chris Jerdonek added the comment: I'm not sure which part of what I wrote you think is inaccurate. All of what you wrote matches what I was trying to convey. For example, my saying "pass to the parent logger" corresponds to the "set current logger to parent"

[issue35821] Clarify when logging events are propagated when propagate is true

Chris Jerdonek added the comment: Thanks for the diagram. How about the following as a replacement? "If this attribute is true and the event isn't rejected by the logger's level and filters, an event passed to this logger will recursively be passed to its parent logger and ha

[issue35821] Clarify when logging events are propagated when propagate is true

Chris Jerdonek added the comment: Also, does "logged to this logger" include events propagated to it from a child logger? For example, if an event is logged to logger "A.B.C" and propagated to "A.B", will the propagate attribute of the latter effect whether logg

[issue35821] Clarify when logging events are propagated when propagate is true

New submission from Chris Jerdonek : Currently, the logging docs are a bit ambiguous or at least not completely clear as to when events are propagated when Logger.propagate is true. The docs currently say [1]-- "If [the `propagate`] attribute evaluates to true, events logged to this l

[issue24780] difflib.ndiff produces unreadable output when input missing trailing newline

Chris Jerdonek added the comment: When I first created the issue, the title I chose was about unittest ("unittest assertEqual difference output foiled by newlines"), but someone else changed it for some reason. You're welcome to change it back to something more like the

[issue29183] Unintuitive error handling in wsgiref when a crash happens in write() or close()

Chris Jerdonek added the comment: This may or may not be the same as what you're suggesting, Martin. But is another option to make close() a no-op if it is called a second time? Otherwise, it seems we'd need to make sure that no code path can result in close() being called twice (even

[issue35105] Document that CPython accepts "invalid" identifiers

Chris Jerdonek added the comment: > In the pydev thread, Guido said "My feeling is that limiting it to strings is > fine, but checking those strings for resembling identifiers is pointless and > wasteful." But in a later message, after additional discussion, he acknow

[issue27682] wsgiref BaseHandler / SimpleHandler can raise additional errors when handling an error

Chris Jerdonek added the comment: This seems like a bug in wsgiref.BaseHandler to me. BaseHandler.run() calls handle_error() if an error occurs inside finish_response(): https://github.com/python/cpython/blob/e2ed5adcb5db2d70cfa72da1ba8446f7aa9e05cd/Lib/wsgiref/handlers.py#L141 However

[issue27682] wsgiref BaseHandler / SimpleHandler can raise additional errors when handling an error

Change by Chris Jerdonek : -- stage: -> test needed title: wsgiref: Windows Error 10053, ConnectionAbortedError: [WinError 10053] An established connection was aborted by the software in your host machine -> wsgiref BaseHandler / SimpleHandler can raise additional error

[issue34547] Wsgiref server does not handle closed connections gracefully

Chris Jerdonek added the comment: Closing this as a duplicate. Please carry over to issue 27682 any PR's that are still current. -- nosy: +chris.jerdonek resolution: -> duplicate stage: patch review -> resolved status: open -> closed superseder: -> wsgiref: Windows

[issue34475] functools.partial objects have no __qualname__ attribute

Chris Jerdonek added the comment: Sorry, I'm out of practice. I thought I closed this when I marked it rejected. -- ___ Python tracker <https://bugs.python.org/issue34

<    1   2   3   4   5   6   7   8   9   10   >