[issue40941] Merge generator.gi_running and frame executing flag into single frame state

2020-07-09 Thread Chris Jerdonek


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

2020-06-10 Thread Chris Jerdonek


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

2020-06-06 Thread Chris Jerdonek


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

2020-06-03 Thread Chris Jerdonek


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

2020-06-03 Thread Chris Jerdonek


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

2020-05-31 Thread Chris Jerdonek


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

2020-05-30 Thread Chris Jerdonek


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")

2020-05-25 Thread Chris Jerdonek


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()

2020-05-23 Thread Chris Jerdonek


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?

2020-05-23 Thread Chris Jerdonek


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

2020-05-23 Thread Chris Jerdonek


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

2020-05-22 Thread Chris Jerdonek


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

2020-05-22 Thread Chris Jerdonek


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

2020-05-22 Thread Chris Jerdonek


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")

2020-05-22 Thread Chris Jerdonek


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")

2020-05-22 Thread Chris Jerdonek


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

2020-05-22 Thread Chris Jerdonek


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

2020-05-22 Thread Chris Jerdonek


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?

2020-05-22 Thread Chris Jerdonek


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()

2020-05-22 Thread Chris Jerdonek


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")

2020-05-22 Thread Chris Jerdonek


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()

2020-05-22 Thread Chris Jerdonek


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?

2020-05-22 Thread Chris Jerdonek


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

2020-05-22 Thread Chris Jerdonek


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

2020-05-22 Thread Chris Jerdonek


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

2020-05-22 Thread Chris Jerdonek


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

2020-05-22 Thread Chris Jerdonek


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

2020-05-22 Thread Chris Jerdonek


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

2020-05-21 Thread Chris Jerdonek


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

2020-05-21 Thread Chris Jerdonek


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

2020-05-21 Thread Chris Jerdonek


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

2020-05-21 Thread Chris Jerdonek


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.

2020-05-21 Thread Chris Jerdonek


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.

2020-05-21 Thread Chris Jerdonek


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.

2020-05-21 Thread Chris Jerdonek


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

2020-05-21 Thread Chris Jerdonek


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

2020-05-20 Thread Chris Jerdonek


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.

2020-05-20 Thread Chris Jerdonek


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.

2020-05-20 Thread Chris Jerdonek


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.

2020-05-20 Thread Chris Jerdonek


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.

2020-05-20 Thread Chris Jerdonek


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.

2020-05-20 Thread Chris Jerdonek


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.

2020-05-20 Thread Chris Jerdonek


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.

2020-05-20 Thread Chris Jerdonek


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.

2020-05-20 Thread Chris Jerdonek


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

2020-05-20 Thread Chris Jerdonek


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

2020-05-20 Thread Chris Jerdonek


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

2020-05-20 Thread Chris Jerdonek


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()

2020-05-19 Thread Chris Jerdonek


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

2020-05-19 Thread Chris Jerdonek


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

2020-05-19 Thread Chris Jerdonek


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

2020-05-19 Thread Chris Jerdonek


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

2020-05-19 Thread Chris Jerdonek


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

2020-05-19 Thread Chris Jerdonek


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

2020-05-19 Thread Chris Jerdonek


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, ...)?

2020-05-18 Thread Chris Jerdonek


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

2020-05-18 Thread Chris Jerdonek


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



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

2020-05-18 Thread Chris Jerdonek


Change by Chris Jerdonek :


--
nosy: +chris.jerdonek

___
Python tracker 
<https://bugs.python.org/issue39060>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



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

2020-05-18 Thread Chris Jerdonek


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.__del__ here:
https://github.com/python/cpython/blob/3764069f3ba2a7e932837ae19265059339dc86e3/Lib/asyncio/tasks.py#L167-L176

The reason to do it this way is that if the Task is still in scope, there's 
still a chance that the caller might want to handle the exception themselves, 
e.g. by awaiting on the Task themselves. It's only when all references to the 
task go away that you know that the Task's exceptions can no longer be handled 
manually.

Maybe this would be worth clarifying somewhere in the Error Handling API docs:
https://docs.python.org/3/library/asyncio-eventloop.html#error-handling-api
If you agree, we can change this issue to a documentation issue.

--

___
Python tracker 
<https://bugs.python.org/issue39839>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



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

2020-05-18 Thread Chris Jerdonek


Change by Chris Jerdonek :


--
nosy: +chris.jerdonek

___
Python tracker 
<https://bugs.python.org/issue39839>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



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

2020-05-18 Thread Chris Jerdonek


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) first. Because if we document it now, then 
it could be interpreted as defined behavior and so harder to change later due 
to backwards compat guarantees.

--

___
Python tracker 
<https://bugs.python.org/issue40672>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



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

2020-05-18 Thread Chris Jerdonek


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


--

___
Python tracker 
<https://bugs.python.org/issue31033>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



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

2020-05-18 Thread Chris Jerdonek


Change by Chris Jerdonek :


--
pull_requests: +19472
pull_request: https://github.com/python/cpython/pull/20173

___
Python tracker 
<https://bugs.python.org/issue31033>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



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

2020-05-18 Thread Chris Jerdonek


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.org/issue40607>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



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

2020-05-18 Thread Chris Jerdonek


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 5, in run
await asyncio.sleep(100)
  File "/.../cpython/Lib/asyncio/tasks.py", line 669, in sleep
return await future
asyncio.exceptions.CancelledError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/.../cpython/Lib/asyncio/tasks.py", line 507, in wait_for
fut.result()
asyncio.exceptions.CancelledError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/.../cpython/test-31131.py", line 15, in 
main(run())
  File "/.../cpython/test-31131.py", line 11, in main
loop.run_until_complete(future)
  File "/.../cpython/Lib/asyncio/base_events.py", line 642, in 
run_until_complete
return future.result()
  File "/.../cpython/Lib/asyncio/tasks.py", line 509, in wait_for
raise exceptions.TimeoutError() from exc
asyncio.exceptions.TimeoutError

As you can see the traceback now includes the exception chain from the 
TimeoutError to the point of interruption: await asyncio.sleep(100).

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Improve traceback of cancelled tasks / add cancel() msg argument
versions: +Python 3.9 -Python 3.6

___
Python tracker 
<https://bugs.python.org/issue31131>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



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

2020-05-17 Thread Chris Jerdonek


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 argument to .cancel() of Task and Future -> Improve traceback of 
cancelled tasks / add cancel() msg argument

___
Python tracker 
<https://bugs.python.org/issue31033>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



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

2020-05-17 Thread Chris Jerdonek


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


--

___
Python tracker 
<https://bugs.python.org/issue31033>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



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

2020-05-17 Thread Chris Jerdonek


Change by Chris Jerdonek :


--
nosy: +chris.jerdonek

___
Python tracker 
<https://bugs.python.org/issue40152>
___
___
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

2020-05-17 Thread Chris Jerdonek


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

2020-05-17 Thread Chris Jerdonek


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: +chris.jerdonek

___
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



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

2020-05-16 Thread Chris Jerdonek


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


--

___
Python tracker 
<https://bugs.python.org/issue29587>
___
___
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)

2020-05-16 Thread Chris Jerdonek


Change by Chris Jerdonek :


--
type:  -> behavior

___
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)

2020-05-16 Thread Chris Jerdonek


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

2020-05-16 Thread Chris Jerdonek


Change by Chris Jerdonek :


--
pull_requests: +19447
pull_request: https://github.com/python/cpython/pull/20142

___
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



[issue32309] Implement asyncio.run_in_executor shortcut

2020-05-16 Thread Chris Jerdonek


Change by Chris Jerdonek :


--
nosy: +chris.jerdonek

___
Python tracker 
<https://bugs.python.org/issue32309>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



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

2020-05-15 Thread Chris Jerdonek


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 each 
time the CancelledError is raised, or only show it in the innermost, 
originating exception. My preference is to do the latter because it is simpler, 
less verbose, and seems more correct from a Python perspective. But I wanted to 
flag this because the message won't be visible in the leading, outermost 
exception.

There is a third alternative which is to mutate the exception each time (delete 
the message from the earlier exception and add it to the new exception). But 
that seems more fraught and what I'd consider surprising behavior.

Lastly, to illustrate, here is the more verbose option (the one I think it 
**shouldn't** look like):

Traceback (most recent call last):
  File "/.../cpython/test-cancel.py", line 4, in nested
await asyncio.sleep(1)
  File "/.../cpython/Lib/asyncio/tasks.py", line 670, in sleep
return await future
asyncio.exceptions.CancelledError: POSSIBLY LONG CANCEL MESSAGE

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/.../cpython/test-cancel.py", line 11, in run
await task
asyncio.exceptions.CancelledError: POSSIBLY LONG CANCEL MESSAGE

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/.../cpython/test-cancel.py", line 15, in 
loop.run_until_complete(run())
  File "/.../cpython/Lib/asyncio/base_events.py", line 642, in 
run_until_complete
return future.result()
asyncio.exceptions.CancelledError: POSSIBLY LONG CANCEL MESSAGE

--
versions: +Python 3.9 -Python 3.5, Python 3.6, Python 3.7

___
Python tracker 
<https://bugs.python.org/issue31033>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



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

2020-05-15 Thread Chris Jerdonek


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 tracker 
<https://bugs.python.org/issue31033>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



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

2020-05-15 Thread Chris Jerdonek


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


--

___
Python tracker 
<https://bugs.python.org/issue31033>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



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

2020-05-13 Thread Chris Jerdonek


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


--

___
Python tracker 
<https://bugs.python.org/issue29587>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40615] unstable behaviour for options in argparse

2020-05-13 Thread Chris Jerdonek


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: ambiguous option: --clea could match --clear-magic, --clear

--

___
Python tracker 
<https://bugs.python.org/issue40615>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40615] unstable behaviour for options in argparse

2020-05-13 Thread Chris Jerdonek


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/issue40615>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



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

2020-05-12 Thread Chris Jerdonek


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

___
Python tracker 
<https://bugs.python.org/issue40607>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue37573] asyncio: freeze when using MultiLoopChildWatcher on Solaris

2020-05-12 Thread Chris Jerdonek


Change by Chris Jerdonek :


--
resolution:  -> duplicate

___
Python tracker 
<https://bugs.python.org/issue37573>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue37573] asyncio: freeze when using MultiLoopChildWatcher on Solaris

2020-05-12 Thread Chris Jerdonek


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 Refleaks 3.x)

___
Python tracker 
<https://bugs.python.org/issue37573>
___
___
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)

2020-05-12 Thread Chris Jerdonek


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 the wakeup file descriptor isn't 
set in the original test is that MultiLoopChildWatcher registers the SIGCHLD 
handler using signal.signal():
https://github.com/python/cpython/blob/74ea6b5a7501fb393cd567fb21998d0bfeeb267c/Lib/asyncio/unix_events.py#L1261-L1267
rather than using loop.add_signal_handler(), which calls signal.set_wakeup_fd():
https://github.com/python/cpython/blob/74ea6b5a7501fb393cd567fb21998d0bfeeb267c/Lib/asyncio/unix_events.py#L95

Is there a reason MultiLoopChildWatcher.attach_loop() isn't calling 
loop.add_signal_handler()? Since attach_loop() has to be called from the main 
thread anyways, it seems like it could be okay.

I also wonder if the documentation could perhaps be more specific as to the 
difference between loop.add_signal_handler() and signal.signal(). Currently, it 
just says callbacks registered with add_signal_handler() are "allowed to 
interact with the event loop":
https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.loop.add_signal_handler
But it doesn't give any warnings about using signal.signal(). For example, it 
might be worth saying something about the possibility of hangs if 
add_signal_handler() isn't used.

--

___
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)

2020-05-11 Thread Chris Jerdonek


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 on a future.

The right amount of time has to elapse between the popen.kill() and the await, 
so I introduced a random bit of variability in between. The right range / 
amount of time to put in between probably depends on the machine. (What you 
want is a narrow range right on the borderline, where sometimes the signal 
fires right before the await, and sometimes right after.) I also added a 
printf() statement at the beginning of signalmodule.c's trip_signal(), so I can 
see in the console whether the signal is firing before or after the await. In 
the timeout / hang case, the signal will be firing after. The hang is very 
infrequent with the script, though (less frequent than the original unittest). 
It can take multiple 1-minute runs.

It seems similar issues have happened a number of times in the past around the 
signal-handling code. See e.g. https://bugs.python.org/issue30038 and changes 
to the neighboring code since then.

--
Added file: https://bugs.python.org/file49150/test-kill3.py

___
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



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

2020-05-11 Thread Chris Jerdonek


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 to address an "Example 3" of this issue (the 
"yield from" case as opposed to the "yield" case, which the merged PR 
addressed):

Example 3:

def f():
yield

def g():
try:
raise KeyError('a')
except Exception:
yield from f()

gen = g()
gen.send(None)
gen.throw(ValueError)

--
Output without PR:

Traceback (most recent call last):
  File "/.../test-example3.py", line 12, in 
gen.throw(ValueError)
  File "/.../test-example3.py", line 8, in g
yield from f()
  File "/.../test-example3.py", line 2, in f
yield
ValueError

--
Output with PR:

Traceback (most recent call last):
  File "/.../test-example3.py", line 6, in g
raise KeyError('a')
KeyError: 'a'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/.../test-example3.py", line 12, in 
gen.throw(ValueError)
  File "/.../test-example3.py", line 8, in g
yield from f()
  File "/.../test-example3.py", line 2, in f
yield
ValueError

--

___
Python tracker 
<https://bugs.python.org/issue29587>
___
___
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)

2020-05-09 Thread Chris Jerdonek


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.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)

2020-05-09 Thread Chris Jerdonek


Chris Jerdonek  added the comment:

I came up with the script by (1) running the test locally and seeing the same 
hang, (2) moving the test function to its own script separate from the unit 
tests and seeing the same hang, and (3) successively stripping away code while 
continuing to check for the same hang. So it should be equivalent.

As for why it's related to signals, it's because of what the script does (it's 
not waiting on a subprocess). All it does is start an event loop and then do 
the following repeatedly:

1. starts a subprocess that sleeps indefinitely
2. create an empty future
3. set a SIGCHLD handler that calls set_result() on the future
4. use call_later() to terminate the future after 5 seconds
4. kill the subprocess
5. await on the future

Almost all of the time, (5) completes immediately (because the handler is 
called immediately). But sometimes, (5) takes 5 seconds (which means the 
timeout fired). And in the cases it takes 5 seconds, I'm able to observe both 
that (a) Python received the SIGCHLD right away, and (b) the signal handler 
only gets called when the loop is woken up by the call_later(). So during the 
await in (5), it seems like Python is holding onto the signal for 5 seconds 
without calling its signal handler.

--

___
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)

2020-05-09 Thread Chris Jerdonek


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, 
my reproducer script doesn't use MultiLoopWatcher. I'd like to see if it can be 
reproduced with signals other than SIGCHLD, too.

--

___
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



[issue37573] asyncio: freeze when using MultiLoopChildWatcher on Solaris

2020-05-09 Thread Chris Jerdonek


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/issue37573>
___
___
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)

2020-05-09 Thread Chris Jerdonek


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

2020-05-09 Thread Chris Jerdonek


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

2020-05-09 Thread Chris Jerdonek


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" happens (which shows up as a timeout). 
I recommend running the script for about 15 seconds, and if it doesn't happen, 
re-run it again. You might need to run it a half-dozen or dozen times to see 
the hang, but it can also happen right away.

I'm sure the script can be cleaned up and simplified a lot more. This is just a 
start. I wanted to see how much of the cruft I could strip out quickly.

This is what the output looks like after one of the hangs:

[81]: 16.77
/.../cpython/Lib/subprocess.py:1048: ResourceWarning: subprocess 3282 is still 
running
  _warn("subprocess %s is still running" % self.pid,
ResourceWarning: Enable tracemalloc to get the object allocation traceback
killing pid: 3283
BaseSubprocessTransport: awaiting in _wait
_sig_child: started
releasing waiter: okay
okay
[82]: 16.99
/.../cpython/Lib/subprocess.py:1048: ResourceWarning: subprocess 3283 is still 
running
  _warn("subprocess %s is still running" % self.pid,
ResourceWarning: Enable tracemalloc to get the object allocation traceback
killing pid: 3284
BaseSubprocessTransport: awaiting in _wait
_sig_child: started
releasing waiter: **TIMEOUT**
not okay: **TIMEOUT**

You can ignore the ResourceWarnings. You can also see at the end that the 
_sig_child() handler was called even in the timeout case (right before the 
loop.call_later(TIMEOUT, ...) callback began).

--
Added file: https://bugs.python.org/file49144/test-kill.py

___
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)

2020-05-08 Thread Chris Jerdonek


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://github.com/python/cpython/blob/7f7e706d78ab968a1221c6179dfdba714860bd12/Lib/test/test_asyncio/test_subprocess.py#L480
 )

Consider this line in asyncio.tasks.wait_for(), which is to trigger the timeout:
https://github.com/python/cpython/blob/7f7e706d78ab968a1221c6179dfdba714860bd12/Lib/asyncio/tasks.py#L476

  timeout_handle = loop.call_later(timeout, _release_waiter, waiter)

I put some debug statements inside _release_waiter, and I found that 
_sig_chld() is called after the timeout has elapsed and before _release_waiter 
starts. So basically, it looks like CPython is holding onto the signal, and 
waiting for the loop to do something more before running the handler and 
calling the _sig_chld().

The code base already has logic to skip running signal handlers in various 
cases, but I don't know whether it relates to this issue:
https://github.com/python/cpython/blob/7f7e706d78ab968a1221c6179dfdba714860bd12/Python/ceval.c#L1410-L1425

It seems like there are a number of issues on the tracker related to signals 
(some solved and others not, e.g. https://bugs.python.org/issue21895 ). So it 
looks to me like this could point to a deeper issue between asyncio and 
CPython's signal handling.

--
nosy: +chris.jerdonek

___
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



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

2020-05-08 Thread Chris Jerdonek


Change by Chris Jerdonek :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue40559>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



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

2020-05-08 Thread Chris Jerdonek


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


--

___
Python tracker 
<https://bugs.python.org/issue40559>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



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

2020-05-08 Thread Chris Jerdonek


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


--

___
Python tracker 
<https://bugs.python.org/issue40559>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



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

2020-05-08 Thread Chris Jerdonek


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


--

___
Python tracker 
<https://bugs.python.org/issue40559>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue31185] Miscellaneous errors in asyncio speedup module

2020-05-08 Thread Chris Jerdonek


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 
<https://bugs.python.org/issue31185>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



  1   2   3   4   5   6   7   8   9   10   >