[issue43923] Can't create generic NamedTuple as of py3.9

Change by Bernie Hackett : -- nosy: +behackett ___ Python tracker <https://bugs.python.org/issue43923> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38890] A subprocess.Popen created with creationFlags=DETACHED_PROCESS on Windows should not emit a ResourceWarning

Change by Bernie Hackett : -- nosy: +behackett ___ Python tracker <https://bugs.python.org/issue38890> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue17123] Add OCSP support to ssl module

Bernie Hackett added the comment: OCSP is the only way Let's Encrypt supports revocation. It would be really useful to have stapling verification supported in the standard library, even just the callback support PyOpenSSL supports. https://letsencrypt.org/docs/revoking/ --

[issue24832] Issue building viewable docs with newer sphinx (default theme -> classic)

Bernie Hackett added the comment: We had the same problem with PyMongo's docs. The issue happens with Sphinx 1.3.0 and 1.3.1. It appears to be resolved in 1.3.2. The changelog includes this line (no issue number is mentioned): Add a “default.css” stylesheet (which imports “classic.css”

[issue25222] 3.5.0 regression - Fatal Python error: Cannot recover from stack overflow

Bernie Hackett added the comment: On second thought, _Py_CheckRecursiveCall may be being called recursively through Py_FatalError. -- ___ Python tracker <http://bugs.python.org/issue25

[issue25222] 3.5.0 regression - Fatal Python error: Cannot recover from stack overflow

Bernie Hackett added the comment: Here's a chunk of the call stack from the Visual Studio debugger using the debug build. Py_FatalError seems to be called multiple times: > ucrtbased.dll!72d27f30()Unknown [Frames below may be incorrect and/or missing, no symbols lo

[issue25222] 3.5.0 regression - Fatal Python error: Cannot recover from stack overflow

Bernie Hackett added the comment: > Clone master from github: You'll also have to git checkout 4bbe2133a14df716b1dffe8ab7957ed67149b2cd to roll back the setrecursionlimit change I added to work around this issue. Using 100 seems to have permanently vanquished the abort, but there&

[issue25222] 3.5.0 regression - Fatal Python error: Cannot recover from stack overflow

Bernie Hackett added the comment: > File > "D:\buildarea\3.4.bolen-windows10\build\lib\test\test_json\test_recursion.py", > line 96 in test_endless_recursion That test (and reason for existence) is almost exactly the same as the PyMongo test that causes abort reported in t

[issue25222] 3.5.0 regression - Fatal Python error: Cannot recover from stack overflow

Bernie Hackett added the comment: I used sys.setrecursionlimit(250) - the default appears to be 1000 on all my test machines - and that reduced the occurrence of the abort but didn't completely solve the problem. There must be something more going on

[issue25222] 3.5.0 regression - Fatal Python error: Cannot recover from stack overflow

Bernie Hackett added the comment: > Well, Python has no perfect protection again stack overflow. It's only best > effect. That's interesting. I thought there was a stronger contract, and it appeared that way in all previous cpython releases back to 2.4. Again, this failure is

[issue25222] 3.5.0 regression - Fatal Python error: Cannot recover from stack overflow

New submission from Bernie Hackett: While running PyMongo's test suite against python 3.5.0 the interpreter inconsistently aborts when we test encoding a recursive data structure like: evil = {} evil['evil'] = evil The test that triggers this was added to test the use of Py_Ent