[issue33622] Fix errors handling in the garbage collector

Change by Serhiy Storchaka : -- title: Fix and improve errors handling in the garbage collector -> Fix errors handling in the garbage collector ___ Python tracker ___ _

[issue33619] libffi detection via pkg-config is broken

Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue33618] Support TLS 1.3

Change by Christian Heimes : -- keywords: +patch pull_requests: +6709 stage: needs patch -> patch review ___ Python tracker ___ ___ P

[issue33546] asyncio.Condition should become awaitable in 3.9

Łukasz Langa added the comment: Andrew is right because a Condition *is* a lock. The confusing thing about this construct is that the actual logic "condition" that we're waiting for is external. It can be controlled by another coroutine that will just let us know by calling `cond.notify()`

[issue33605] Detect accessing event loop from a different thread outside of _debug

Hrvoje Nikšić added the comment: > I'd be OK with this if the performance penalty is within 0.5% in > microbenchmarks for asyncio & uvloop. @yselivanov Are you referring to specific microbenchmarks published somewhere, or the general "echo server" style microbenchmarks? -- _

[issue33605] Detect accessing event loop from a different thread outside of _debug

Yury Selivanov added the comment: Echo server is usually a good enough microbenchmark (you can use benchmarks from uvloop/examples). Repeatedly calling call_soon would also be an interesting micro-benchmark but less important (unless it shows that call_soon is 2x slower or something). -

[issue33623] Fix possible SIGSGV when asyncio.Future is created in __del__

New submission from Yury Selivanov : Originally reported in https://github.com/MagicStack/uvloop/issues/143 Future.__init__ shouldn't try to capture the current traceback if the interpreter is being finalized. -- messages: 317437 nosy: yselivanov priority: normal severity: normal statu

[issue33623] Fix possible SIGSGV when asyncio.Future is created in __del__

Change by Yury Selivanov : -- keywords: +patch pull_requests: +6710 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-li

[issue33624] Implement subclass hooks for asyncio abstract classes

New submission from Andrew Svetlov : To make clean inheritance hierarchy of objects implemented by third-party loop implementations. Now is impossible to implement AbstractServer in C or Cython. See also https://github.com/MagicStack/uvloop/issues/131 -- components: asyncio messages: 3

[issue33623] Fix possible SIGSGV when asyncio.Future is created in __del__

Change by Yury Selivanov : -- components: +asyncio nosy: +asvetlov ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue33623] Fix possible SIGSGV when asyncio.Future is created in __del__

Change by Yury Selivanov : -- type: -> crash ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyt

[issue33565] strange tracemalloc results

Alexander Mohr added the comment: actually, thinking about this more on my way to work, this should NOT be closed. The callstack I initially mentioned still has no explanation and we now know is not correct. It should either have listed something related to warnings, or nothing at all () or

[issue33623] Fix possible SIGSGV when asyncio.Future is created in __del__

Serhiy Storchaka added the comment: Is the problem because traceback_extract_stack is NULL? But this will not fix the problem completely. For example calling repr() on a future can crash because of asyncio_future_repr_info_func == NULL. And many other operations use globals cleared in module_

[issue33623] Fix possible SIGSGV when asyncio.Future is created in __del__

Yury Selivanov added the comment: > Is the problem because traceback_extract_stack is NULL? It's not NULL, it's just a broken reference at that point. -- ___ Python tracker __

[issue33612] Assertion failure in PyThreadState_Clear

Ned Deily added the comment: New changeset 508d7693bc09affd99fdaa4a321cc3da0638c8a0 by Ned Deily (Miss Islington (bot)) in branch '3.7': bpo-33612: Remove PyThreadState_Clear() assertion (GH-7069) (GH-7074) https://github.com/python/cpython/commit/508d7693bc09affd99fdaa4a321cc3da0638c8a0 ---

[issue25612] nested try..excepts don't work correctly for generators

Ned Deily added the comment: New changeset 508d7693bc09affd99fdaa4a321cc3da0638c8a0 by Ned Deily (Miss Islington (bot)) in branch '3.7': bpo-33612: Remove PyThreadState_Clear() assertion (GH-7069) (GH-7074) https://github.com/python/cpython/commit/508d7693bc09affd99fdaa4a321cc3da0638c8a0 ---

[issue33625] Disable GIL on getpwnam and getpwuid

New submission from William Grzybowski : Hello, Currently the GIL is not disabled when calling pwd.getpwnam nor pwd.getpwuid. It could be the C library call may take some time for completion, especially when using third-party modules on the system (nss-ldap, nss-pgsql, sss, etc). Disabling GI

[issue33625] Disable GIL on getpwnam and getpwuid

Change by William Grzybowski : -- keywords: +patch pull_requests: +6711 stage: -> patch review ___ Python tracker ___ ___ Python-bug

[issue33623] Fix possible SIGSGV when asyncio.Future is created in __del__

Serhiy Storchaka added the comment: Then we should find what callable is NULL and fix the place where it is called. _PyObject_FastCallDict() should never be called with NULL. -- ___ Python tracker __

[issue33605] Detect accessing event loop from a different thread outside of _debug

Andrew Svetlov added the comment: Heh, should we sacrifice performance? Documentation for asyncio explicitly states that the only safe interthreading call is `call_soon_threadsafe()`. If people use multithreaded environments with asyncio (Why? Usually `run_in_executor()` doesn't require commu

[issue33625] Disable GIL on getpwnam and getpwuid

Christian Heimes added the comment: Since your patch is a bug fix, it can be back-ported to 2.7 and 3.6/3.7. -- nosy: +christian.heimes type: -> behavior versions: +Python 2.7, Python 3.7, Python 3.8 ___ Python tracker

[issue33618] Support TLS 1.3

Ned Deily added the comment: > Ned, Benjamin, are you OK with that? Just to be clear, you wish to merge a backport of PR 7079 for 3.7.0rc1? -- ___ Python tracker ___ _

[issue33618] Support TLS 1.3

Christian Heimes added the comment: Yes, if that's ok with you. It's only documentation and test updates. -- ___ Python tracker ___

[issue32911] Doc strings no longer stored in body of AST

Serhiy Storchaka added the comment: Maybe we will need to return to this issue in future and merge Inada's patch. IPython has been needed to add a workaround for this change. [1] And maybe Python will be needed to add that workaround if once it will add the support of pasting multiple complex

[issue33618] Support TLS 1.3

Ned Deily added the comment: As long as it doesn't break 1.0.2 and 1.1.0 support, sure :) -- ___ Python tracker ___ ___ Python-bugs-

[issue33618] Support TLS 1.3

Christian Heimes added the comment: Tests with 1.0.2o and 1.1.0h are passing. -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue33618] Support TLS 1.3

Christian Heimes added the comment: New changeset 529525fb5a8fd9b96ab4021311a598c77588b918 by Christian Heimes in branch 'master': bpo-33618: Enable TLS 1.3 in tests (GH-7079) https://github.com/python/cpython/commit/529525fb5a8fd9b96ab4021311a598c77588b918 -- __

[issue33618] Support TLS 1.3

Change by miss-islington : -- pull_requests: +6713 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mai

[issue33609] Document that dicts preserve insertion order

Ned Deily added the comment: I agree with Yury's suggestions; the entry in the "Dictionary view objects" section, that Cheryl points to, is not sufficient. Is somebody willing to write a PR? -- priority: normal -> high stage: -> needs patch type: enhancement -> ___

[issue33618] Support TLS 1.3

Christian Heimes added the comment: New changeset 72ef4fc32b354f8e56eec64f4c15ac2e07d118be by Christian Heimes (Miss Islington (bot)) in branch '3.7': [3.7] bpo-33618: Enable TLS 1.3 in tests (GH-7079) (GH-7082) https://github.com/python/cpython/commit/72ef4fc32b354f8e56eec64f4c15ac2e07d118be

[issue33463] Can namedtuple._asdict return a regular dict instead of OrderedDict?

Michael Selik added the comment: I changed the PR to simply replace OrderedDict with dict. For the docs warnings, if I'm understanding correctly, those should be separate pulls for older branches? -- ___ Python tracker

[issue33614] Compilation of Python fails on AMD64 Windows8.1 Refleaks 3.x

Ned Deily added the comment: (for example, http://buildbot.python.org/all/#/builders/133/builds/251 ) -- ___ Python tracker ___ ___

[issue33612] Assertion failure in PyThreadState_Clear

STINNER Victor added the comment: Mark Shannon, the author of the assertion, approved my PR to remove the assertion: https://github.com/python/cpython/pull/7069#issuecomment-391342700 The initial issue, the failing assertion, has been fixed. Well, to be honest, I failed to reproduce Serhiy's

[issue33614] Compilation of Python fails on AMD64 Windows8.1 Refleaks 3.x

Ned Deily added the comment: > All the critical builds should forcibly rebuild it, so this isn't urgent, but > I'll take a look next time I get a chance to work on the build files. It's more than a *bit* urgent since it is causing one of the 3.7 stable buildbots to fail to build and not run t

[issue33614] Compilation of Python fails on AMD64 Windows8.1 Refleaks 3.x

Change by Ned Deily : -- versions: +Python 3.7 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.py

[issue27535] Ignored ResourceWarning warnings leak memory in warnings registries

STINNER Victor added the comment: Alexander Mohr reported a memory leak in his code using botocore (Python client for Amazon S3): bpo-33565. His code emited ResourceWarning, but these warnings are ignored by default. The link between ignored warnings and a memory leak is non obvious. Serhiy:

[issue33355] Windows 10 buildbot: 15 min timeout on test_mmap.test_large_filesize()

STINNER Victor added the comment: test_mmap.test_large_offset() failed on x86 Windows7 3.7: http://buildbot.python.org/all/#/builders/111/builds/265 David Bolen: do you prefer to upgrade the VM to a faster account on Azure, or change the timeout? 0:41:01 [144/415/1] test_mmap crashed (Exit

[issue33615] test__xxsubinterpreters crashed on x86 Gentoo Refleaks 3.x

Eric Snow added the comment: FTR, this started happening after the following commit: commit 6d2cd9036c0ab78a83de43d1511befb7a7fc0ade Author: Eric Snow Date: Wed May 16 15:04:57 2018 -0400 bpo-32604: Improve subinterpreter tests. (#6914) Add more tests for subinterpreters. This patc

[issue33614] Compilation of Python fails on AMD64 Windows8.1 Refleaks 3.x

Ned Deily added the comment: Steve: just a minute ago, zware out the win8.1 bot's repo and restarted a 3.7 build. -- ___ Python tracker ___ ___

[issue33614] Compilation of Python fails on AMD64 Windows8.1 Refleaks 3.x

Steve Dower added the comment: Okay, I'll take a look now. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33614] Compilation of Python fails on AMD64 Windows8.1 Refleaks 3.x

Ned Deily added the comment: er, "cleaned out" -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mai

[issue33355] Windows 10 buildbot: 15 min timeout on test_mmap.test_large_filesize()

David Bolen added the comment: The win7 builder isn't on Azure, so changing host type isn't an option at the moment. For my part, I'd prefer removing the largefile tests for that one rather than increasing timeout. The tests generate a huge amount of I/O, so my guess is it's just not practi

[issue33355] Windows 10 buildbot: 15 min timeout on test_mmap.test_large_filesize()

Ned Deily added the comment: Thanks, David. Yes, I think disabling "largefile" tests on that buildbot makes the most sense. We're working on it. -- nosy: +ned.deily ___ Python tracker _

[issue32458] test_asyncio: test_start_tls_server_1() fails randomly

STINNER Victor added the comment: test_start_tls_server_1() just failed on my Linux. It likely depends on the system load. -- nosy: +vstinner title: test_asyncio failures on Windows -> test_asyncio: test_start_tls_server_1() fails randomly ___ Pyth

[issue33353] test_asyncio: test_sock_sendfile_mix_with_regular_send() hangs on FreeBSD

Change by STINNER Victor : -- keywords: +patch pull_requests: +6714 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-li

[issue32622] Implement loop.sendfile

Change by STINNER Victor : -- pull_requests: +6715 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mai

[issue32458] test_asyncio: test_start_tls_server_1() fails randomly

Change by Antoine Pitrou : -- nosy: -pitrou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyth

[issue32622] Implement loop.sendfile

STINNER Victor added the comment: New changeset 2932755cc11fd82b4908d60b24b837aa4f3028e6 by Victor Stinner in branch 'master': bpo-33353: test_asyncio uses smaller sendfile data (#7083) https://github.com/python/cpython/commit/2932755cc11fd82b4908d60b24b837aa4f3028e6 --

[issue33353] test_asyncio: test_sock_sendfile_mix_with_regular_send() hangs on FreeBSD

STINNER Victor added the comment: New changeset 2932755cc11fd82b4908d60b24b837aa4f3028e6 by Victor Stinner in branch 'master': bpo-33353: test_asyncio uses smaller sendfile data (#7083) https://github.com/python/cpython/commit/2932755cc11fd82b4908d60b24b837aa4f3028e6 --

[issue33353] test_asyncio: test_sock_sendfile_mix_with_regular_send() hangs on FreeBSD

Change by miss-islington : -- pull_requests: +6716 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mai

[issue32622] Implement loop.sendfile

Change by miss-islington : -- pull_requests: +6717 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mai

[issue33626] test_sendfile_fallback_close_peer_in_middle_of_receiving() fails on x86-64 Sierra 3.x

New submission from STINNER Victor : http://buildbot.python.org/all/#/builders/14/builds/1023 == FAIL: test_sendfile_fallback_close_peer_in_middle_of_receiving (test.test_asyncio.test_events.KqueueEventLoopTests) --

[issue33216] [3.5] Wrong order of stack for CALL_FUNCTION_VAR and CALL_FUNCTION_VAR_KW

Change by STINNER Victor : -- title: Wrong order of stack for CALL_FUNCTION_VAR and CALL_FUNCTION_VAR_KW -> [3.5] Wrong order of stack for CALL_FUNCTION_VAR and CALL_FUNCTION_VAR_KW ___ Python tracker ___

[issue33216] [3.5] Wrong order of stack for CALL_FUNCTION_VAR and CALL_FUNCTION_VAR_KW

Larry Hastings added the comment: Serhiy, why did you mark this as a release blocker? This is a proposed documentation fix. -- priority: release blocker -> low ___ Python tracker ___

[issue33627] test_numeric_tower.test_complex() crashed on

New submission from STINNER Victor : http://buildbot.python.org/all/#/builders/88/builds/1044 0:07:59 load avg: 1.58 [107/416/1] test_numeric_tower crashed (Exit code -11) Fatal Python error: Segmentation fault Current thread 0x405c4dc0 (most recent call first): File "/srv/buildbot/buildarea

[issue33216] [3.5] Wrong order of stack for CALL_FUNCTION_VAR and CALL_FUNCTION_VAR_KW

Larry Hastings added the comment: Documentation changes are okay. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubs

[issue33627] test_numeric_tower.test_complex() crashed on x86 Ubuntu Shared 3.x

Change by STINNER Victor : -- components: +Tests title: test_numeric_tower.test_complex() crashed on -> test_numeric_tower.test_complex() crashed on x86 Ubuntu Shared 3.x type: -> crash versions: +Python 3.8 ___ Python tracker

[issue33216] [3.5] Wrong order of stack for CALL_FUNCTION_VAR and CALL_FUNCTION_VAR_KW

STINNER Victor added the comment: If the issue is specific to Python 3.5, we can no longer fix it since 3.5 doesn't accept bugfixes anymore. No? -- nosy: +vstinner ___ Python tracker

[issue33615] test__xxsubinterpreters crashed on x86 Gentoo Refleaks 3.x

Eric Snow added the comment: There are a couple of other buildbots with the same failure: ARMv7 Ubuntu 3.x: http://buildbot.python.org/all/#/builders/106/builds/1066 PPC64 AIX 3.x: http://buildbot.python.org/all/#/builders/10/builds/1005 -- ___ Py

[issue33626] test_sendfile_fallback_close_peer_in_middle_of_receiving() fails on x86-64 Sierra 3.x

STINNER Victor added the comment: The regression seems to be caused by my test_asyncio change for bpo-33353: commit 2932755cc11fd82b4908d60b24b837aa4f3028e6 -- ___ Python tracker _

[issue33628] IDLE: Code cleanup on codecontext

New submission from Cheryl Sabella : Based on the github comments on PR5638, some code cleanup issues identified for codecontext. codecontext * getspacesfirstword - function and param1 name * get_line_info - make into helper function and change parm * get_context - call to get_line_info sends t

[issue33610] IDLE: Make multiple improvements to CodeContext

Cheryl Sabella added the comment: For item 2 - #33628 -- dependencies: +IDLE: Code cleanup on codecontext ___ Python tracker ___ ___

[issue33628] IDLE: Code cleanup on codecontext

Change by Cheryl Sabella : -- keywords: +patch pull_requests: +6718 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-li

[issue32622] Implement loop.sendfile

Change by STINNER Victor : -- pull_requests: +6720 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mai

[issue33353] test_asyncio: test_sock_sendfile_mix_with_regular_send() hangs on FreeBSD

Change by STINNER Victor : -- pull_requests: +6719 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mai

[issue33626] test_sendfile_fallback_close_peer_in_middle_of_receiving() fails on x86-64 Sierra 3.x

STINNER Victor added the comment: I close this issue to move again the discussion to bpo-33353. -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> test_asyncio: test_sock_sendfile_mix_with_regular_send() hangs on FreeBSD ___

[issue33353] test_asyncio: test_sock_sendfile_mix_with_regular_send() hangs on FreeBSD

STINNER Victor added the comment: My change caused a regression on macOS: bpo-33626. I just closed this issue as a duplicate of this one. -- ___ Python tracker ___ ___

[issue33353] test_asyncio: test_sock_sendfile_mix_with_regular_send() hangs on FreeBSD

STINNER Victor added the comment: New changeset b97de3dd86046ac46567146d86a69d4f78ea09db by Victor Stinner in branch 'master': bpo-33353: test_asyncio set SO_SNDBUF after connect (GH-7086) https://github.com/python/cpython/commit/b97de3dd86046ac46567146d86a69d4f78ea09db -- _

[issue32622] Implement loop.sendfile

STINNER Victor added the comment: New changeset b97de3dd86046ac46567146d86a69d4f78ea09db by Victor Stinner in branch 'master': bpo-33353: test_asyncio set SO_SNDBUF after connect (GH-7086) https://github.com/python/cpython/commit/b97de3dd86046ac46567146d86a69d4f78ea09db -- _

[issue33353] test_asyncio: test_sock_sendfile_mix_with_regular_send() hangs on FreeBSD

Change by STINNER Victor : -- pull_requests: +6721 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mai

[issue33611] Fatal Python error: Py_Initialize: unable to load the file system codec

INADA Naoki added the comment: > if it could be broken installation or configuration (like incorrectly set > PYTHONHOME or any other python related environment variables), then this > crash should be expected every time I invoke python executable and attempt > to run python scripts. > However, i

[issue33540] socketserver: Add an opt-in option to get Python 3.6 behaviour on server_close()

STINNER Victor added the comment: New changeset 453bd0bc65b7ea6a18c43da69143ab10d54c0a35 by Victor Stinner in branch 'master': bpo-33540: Add block_on_close attr to socketserver (GH-6911) https://github.com/python/cpython/commit/453bd0bc65b7ea6a18c43da69143ab10d54c0a35 -- __

[issue33611] Fatal Python error: Py_Initialize: unable to load the file system codec

INADA Naoki added the comment: > We should maybe dump sys.path into stderr on the specific "unable to load the > file system codec" error. In addition to sys.path, I think "What's current python home (prefix and exec-prefix), and where it come from" is very useful. I recently fixed Vim's bug

[issue33540] socketserver: Add an opt-in option to get Python 3.6 behaviour on server_close()

Change by miss-islington : -- pull_requests: +6722 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mai

[issue33611] Fatal Python error: Py_Initialize: unable to load the file system codec

STINNER Victor added the comment: I completed the _PyCoreConfig structure to add home, module_search_path_env, and many other options. It might help to guess how the final configuration has been computed. I also reworked the code to clarify when and how sys.path is computed. sys.path value (n

[issue33353] test_asyncio: test_sock_sendfile_mix_with_regular_send() hangs on FreeBSD

STINNER Victor added the comment: New changeset fa24c1c5afa9ba2453d88db5ed6b9d2cc3b58384 by Victor Stinner in branch '3.7': [3.7] bpo-33353: Fix test_asyncio on FreeBSD (GH-7087) https://github.com/python/cpython/commit/fa24c1c5afa9ba2453d88db5ed6b9d2cc3b58384 -- ___

[issue32622] Implement loop.sendfile

STINNER Victor added the comment: New changeset fa24c1c5afa9ba2453d88db5ed6b9d2cc3b58384 by Victor Stinner in branch '3.7': [3.7] bpo-33353: Fix test_asyncio on FreeBSD (GH-7087) https://github.com/python/cpython/commit/fa24c1c5afa9ba2453d88db5ed6b9d2cc3b58384 -- ___

[issue32911] Doc strings no longer stored in body of AST

INADA Naoki added the comment: If Python 3.7 is released with current AST form, I don't want to change it again. I prefer * Merge my patch in 3.7rc1, or * Add compile(..., "multi") mode for "sequence of statements" -- ___ Python tracker

[issue32911] Doc strings no longer stored in body of AST

Ned Deily added the comment: > * Merge my patch in 3.7rc1, or Sorry but we are not going to revisit this decision for 3.7.0. It's too late! -- ___ Python tracker ___

[issue32911] Doc strings no longer stored in body of AST

STINNER Victor added the comment: IMHO Python 3.7 will be simpler to process, since it avoids to check if the first node is a docstring or not. I agree that it's a backward incompatible, but it has been done on purpose. In fact, there is no warranty about backward compatibility on the genreat

[issue33540] socketserver: Add an opt-in option to get Python 3.6 behaviour on server_close()

miss-islington added the comment: New changeset fa286edbde9ed660d99628aea14ee3b824c2afe6 by Miss Islington (bot) in branch '3.7': bpo-33540: Add block_on_close attr to socketserver (GH-6911) https://github.com/python/cpython/commit/fa286edbde9ed660d99628aea14ee3b824c2afe6 -- nosy: +m

[issue32708] test_sendfile() hangs on AMD64 FreeBSD 10.x Shared 3.x buildbot

STINNER Victor added the comment: Duplicate of bpo-33353. -- resolution: -> fixed stage: -> resolved status: open -> closed superseder: -> test_asyncio: test_sock_sendfile_mix_with_regular_send() hangs on FreeBSD ___ Python tracker

[issue33353] test_asyncio: test_sock_sendfile_mix_with_regular_send() hangs on FreeBSD

STINNER Victor added the comment: bpo-32708 has been marked as a duplicate of this issue. -- ___ Python tracker ___ ___ Python-bugs-

[issue33629] test_importlib creates a coredump on AMD64 FreeBSD 10.x Shared 3.7

New submission from STINNER Victor : http://buildbot.python.org/all/#/builders/124/builds/315 Warning -- files was modified by test_importlib Before: [] After: ['python.core'] -- components: FreeBSD, Tests messages: 317497 nosy: koobs, vstinner priority: normal severity: normal sta

[issue33565] strange tracemalloc results

INADA Naoki added the comment: > The callstack I initially mentioned still has no explanation and we now know > is not correct. I don't think so. The callstack is Python's callstack where caused leak in C. (Python doesn't call malloc directly) In this case, local variables are freed "at end

[issue26510] [argparse] Add required argument to add_subparsers

Ned Deily added the comment: New changeset 8ebf5ceb0f5408d1ebc26c19702ac0762ef5ea04 by Ned Deily in branch 'master': bpo-33109: argparse subparsers are once again not required by default (GH-6919) https://github.com/python/cpython/commit/8ebf5ceb0f5408d1ebc26c19702ac0762ef5ea04 -- no

[issue33109] argparse: make new 'required' argument to add_subparsers default to False instead of True

Ned Deily added the comment: New changeset 8ebf5ceb0f5408d1ebc26c19702ac0762ef5ea04 by Ned Deily in branch 'master': bpo-33109: argparse subparsers are once again not required by default (GH-6919) https://github.com/python/cpython/commit/8ebf5ceb0f5408d1ebc26c19702ac0762ef5ea04 -- _

[issue33109] argparse: make new 'required' argument to add_subparsers default to False instead of True

Change by miss-islington : -- pull_requests: +6723 stage: commit review -> patch review ___ Python tracker ___ ___ Python-bugs-list m

[issue26510] [argparse] Add required argument to add_subparsers

Change by miss-islington : -- pull_requests: +6724 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mai

[issue33565] strange tracemalloc results

Alexander Mohr added the comment: ok fair enough, however a caveat is that it's not necessarily end of function as I was able to expand the function by a few more lines and the callstack stayed the same, however I'm guessing the interpreter was smart enough to realize the calls below the try/

[issue33540] socketserver: Add an opt-in option to get Python 3.6 behaviour on server_close()

STINNER Victor added the comment: I added the block_on_close class attribute to Python 3.7 and master. I'm not really proud of it, but it's the price of the backward compatibility! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed

[issue33353] test_asyncio: test_sock_sendfile_mix_with_regular_send() hangs on FreeBSD

STINNER Victor added the comment: test_asyncio doesn't hang on FreeBSD 3.x buildbot anymore! macOS buildbot is back to green as well. It seems like I can close the issue. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed __

[issue33629] test_importlib creates a coredump on AMD64 FreeBSD 10.x Shared 3.7

STINNER Victor added the comment: The problem comes from MultiPhaseExtensionModuleTests.test_bad_traverse() of Lib/test/test_importlib/extension/test_loader.py. This test runs the following code: --- import importlib.util as util spec = util.find_spec('_testmultiphase') spec.name = '_testmulti

[issue33628] IDLE: Code cleanup on codecontext

Terry J. Reedy added the comment: Super list. It made the diff really easy to parse into related changes. I printed it, reviewed code for items one by one, made a few changes, and checked them off when satisfied. IDLE *does* (sort of) allow tabs. One can read a file with tabs or Format =>

[issue33629] test_importlib creates a coredump on AMD64 FreeBSD 10.x Shared 3.7

Change by STINNER Victor : -- keywords: +patch pull_requests: +6725 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-li

[issue32374] Document that m_traverse for multi-phase initialized modules can be called with m_state=NULL

Change by STINNER Victor : -- pull_requests: +6726 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mai

[issue32374] Document that m_traverse for multi-phase initialized modules can be called with m_state=NULL

STINNER Victor added the comment: MultiPhaseExtensionModuleTests.test_bad_traverse() of Lib/test/test_importlib/extension/test_loader.py does create a coredump file. The script run by the test trigger a segfault. Is it deliberate? See bpo-33629 and my PR 7090. -- nosy: +vstinner ___

[issue33629] test_importlib creates a coredump on AMD64 FreeBSD 10.x Shared 3.7

STINNER Victor added the comment: The test creating the coredump has been added by bpo-32374. -- ___ Python tracker ___ ___ Python-b

[issue33628] IDLE: Code cleanup on codecontext

Terry J. Reedy added the comment: New changeset 8506016f904ba6bc27bf5261f27a0bdd5945cd26 by Terry Jan Reedy (Cheryl Sabella) in branch 'master': bpo-33628: IDLE: Minor code cleanup of codecontext.py and its tests (GH-7085) https://github.com/python/cpython/commit/8506016f904ba6bc27bf5261f27a

[issue33630] test_posix: TestPosixSpawn fails on PPC64 Fedora 3.x

New submission from STINNER Victor : http://buildbot.python.org/all/#/builders/53/builds/1062 (...) test_close_file (test.test_posix.TestPosixSpawn) ... ok test_dup2 (test.test_posix.TestPosixSpawn) ... ok test_empty_file_actions (test.test_posix.TestPosixSpawn) ... ok test_multiple_file_actions

<    1   2   3   >