[issue33966] test_multiprocessing_spawn.WithProcessesTestPool.test_traceback() leaks 4 handles on Windows

Change by STINNER Victor : -- pull_requests: +7573 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33932] Calling Py_Initialize() twice now triggers a fatal error (Python 3.7)

Change by Nick Coghlan : -- pull_requests: +7574 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33981] test_asyncio: test_sendfile_close_peer_in_the_middle_of_receiving() logs a big error

New submission from STINNER Victor : Python 3.8 (master) on Windows 10: C:\vstinner\python\master>python -m test test_asyncio -m test_sendfile_close_peer_in_the_middle_of_receiving -v Running Debug|x64 interpreter... == CPython 3.8.0a0 (heads/wip:dd08b85c84, Jun 26 2018, 12:47:56) [MSC v.1914

[issue31647] asyncio: StreamWriter write_eof() after close raises mysterious AttributeError

twisteroid ambassador added the comment: Well, I opened the PR, it shows up here, but there's no reviewer assigned. -- ___ Python tracker ___

[issue33981] test_asyncio: test_sendfile_close_peer_in_the_middle_of_receiving() logs a big error

STINNER Victor added the comment: See also bpo-32710: "test_asyncio leaked [4, 4, 3] memory blocks, sum=11 on AMD64 Windows8.1 Refleaks 3.x". -- ___ Python tracker ___

[issue33823] concurrent.futures: cannot specify the number of cores

STINNER Victor added the comment: The first argument of ProcessPoolExecutor is the maximum number of workers. You can use os.cpu_count() to get the number of CPU cores. https://docs.python.org/dev/library/concurrent.futures.html#concurrent.futures.ProcessPoolExecutor I don't see anything

[issue33929] test_multiprocessing_spawn: WithProcessesTestProcess.test_many_processes() leaks 5 handles on Windows

STINNER Victor added the comment: New changeset 7b5856e7f059748f41f37d00abc76be0807d989d by Victor Stinner in branch '3.7': Revert "bpo-33929: multiprocessing: fix handle leak on race condition (GH-7921)" (GH-7963)

[issue33932] Calling Py_Initialize() twice now triggers a fatal error (Python 3.7)

Nick Coghlan added the comment: I went ahead and closed my PR, as I'm now happy that keeping this behaviour isn't going to block anything we want to do for PEP 432. If we change our minds and decide we want to deprecate the current behaviour after all, then we can start that deprecation

[issue33932] Calling Py_Initialize() twice now triggers a fatal error (Python 3.7)

STINNER Victor added the comment: Please keep it open until 3.7.0 is released. -- resolution: fixed -> status: closed -> open ___ Python tracker ___

[issue33981] test_asyncio: test_sendfile_close_peer_in_the_middle_of_receiving() logs a big error

STINNER Victor added the comment: Oh, it's a duplicate of bpo-33834. -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Test for ProactorEventLoop logs InvalidStateError ___ Python tracker

[issue33834] Test for ProactorEventLoop logs InvalidStateError

STINNER Victor added the comment: bpo-33981 has been marked as a duplicate of this issue. Copy of messages: msg320583 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-06-27 14:26 Python 3.8 (master) on Windows 10: C:\vstinner\python\master>python -m test

[issue33834] test_asyncio: test_sendfile_close_peer_in_the_middle_of_receiving() of ProactorEventLoop logs InvalidStateError error

Change by STINNER Victor : -- title: Test for ProactorEventLoop logs InvalidStateError -> test_asyncio: test_sendfile_close_peer_in_the_middle_of_receiving() of ProactorEventLoop logs InvalidStateError error ___ Python tracker

[issue33939] Provide a robust O(1) mechanism to check for infinite iterators

Erik Bray added the comment: > Thinking about the generator-iterator case a bit more, "False" would be a bad > default for that. Allowing "NotImplemented" to indicate the ambiguous "Might > be finite, might be infinite" state, and using that as the default for > generator-iterators, would

[issue33938] Cross compilation fail for ARM

David added the comment: After using --with-system-ffi and setting the correct LD_LIBRARY_PATH, it worked. Many thanks for the help! -- stage: -> resolved status: open -> closed ___ Python tracker

[issue31647] asyncio: StreamWriter write_eof() after close raises mysterious AttributeError

Ned Deily added the comment: New changeset 4a8b037d2b9c7199890bc5a01b3a40687a5ce2b1 by Ned Deily (twisteroid ambassador) in branch 'master': bpo-31647: Fix bpo typo in NEWS entry. (GH-7964) https://github.com/python/cpython/commit/4a8b037d2b9c7199890bc5a01b3a40687a5ce2b1 --

[issue33939] Provide a robust O(1) mechanism to check for infinite iterators

Antoine Pitrou added the comment: I think being able to handle Ctrl-C would be the right solution here. Not handling Ctrl-C is a problem also for very long but non-infinite iterators. -- ___ Python tracker

[issue33980] SSL Error when uploading package to your own pypi

New submission from javi : Hi I am trying to upload a package to a local Pypi repo i have created, and when trying to do it, im having an ssl error since this repository is under a self signed certificate Using pip, there is an option, --trusted-host, that you can use to ignore ssl

[issue33823] concurrent.futures: cannot specify the number of cores

Change by STINNER Victor : -- components: +Library (Lib) -asyncio title: A BUG in concurrent/asyncio -> concurrent.futures: cannot specify the number of cores ___ Python tracker

[issue18174] Make regrtest with --huntrleaks check for fd leaks

Change by STINNER Victor : -- pull_requests: +7575 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue30356] test_mymanager_context() of test_multiprocessing_spawn: manager._process.exitcode=-15 on x86 Windows7 3.x

Change by miss-islington : -- pull_requests: +7578 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue30356] test_mymanager_context() of test_multiprocessing_spawn: manager._process.exitcode=-15 on x86 Windows7 3.x

Change by miss-islington : -- pull_requests: +7577 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33715] test_multiprocessing_spawn.test_wait_result() failed on x86 Windows7 3.x

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

[issue30356] test_mymanager_context() of test_multiprocessing_spawn: manager._process.exitcode=-15 on x86 Windows7 3.x

STINNER Victor added the comment: Python 2.7 terminates the manager process if it takes longer than 200 ms to stop (Python 3 uses a limit of 1 second), but test_multiprocessing doesn't test the exit code of the manager process and so Python 2.7 is not impacted by this bug. --

[issue30356] test_mymanager_context() of test_multiprocessing_spawn: manager._process.exitcode=-15 on x86 Windows7 3.x

STINNER Victor added the comment: > I see different options: (...) * Allow -signal.SIGTERM exit code in > test_mymanager_context() When I discussed with Davin, he told me that it's an acceptable solution. So I wrote the PR 7968 to implement this trivial fix. --

[issue33974] _stringify handles quoted strings incorrectly

Gauchj added the comment: I tried to display entries from the Windows Registry in a TreeView. -- ___ Python tracker ___ ___

[issue30356] test_mymanager_context() of test_multiprocessing_spawn: manager._process.exitcode=-15 on x86 Windows7 3.x

miss-islington added the comment: New changeset 34f2935dca7bb20cd87e42dc41985cc3d688a735 by Miss Islington (bot) in branch '3.7': bpo-30356: Fix test_mymanager_context() of multiprocessing (GH-7968) https://github.com/python/cpython/commit/34f2935dca7bb20cd87e42dc41985cc3d688a735

[issue33913] test_multiprocessing_spawn random failures on x86 Windows7 3.6

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

[issue30339] test_multiprocessing_main_handling: "RuntimeError: Timed out waiting for results" on x86 Windows7 3.x

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

[issue30356] test_mymanager_context() of test_multiprocessing_spawn: manager._process.exitcode=-15 on x86 Windows7 3.x

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

[issue33735] test_multiprocessing_spawn leaked [1, 2, 1] memory blocks on AMD64 Windows8.1 Refleaks 3.7

STINNER Victor added the comment: I also created bpo-33966: "test_multiprocessing_spawn.WithProcessesTestPool.test_traceback() leaks 4 handles on Windows". -- ___ Python tracker

[issue33913] test_multiprocessing_spawn random failures on x86 Windows7 3.6

STINNER Victor added the comment: See also bpo-30339 and bpo-33715 (PR 7971). -- ___ Python tracker ___ ___ Python-bugs-list

[issue33913] test_multiprocessing_spawn random failures on x86 Windows7 3.6

STINNER Victor added the comment: FAIL: test_timeout (test.test_multiprocessing_spawn.WithThreadsTestQueue) -- Traceback (most recent call last): File

[issue33982] cgi.FieldStorage doesn't parse QUERY_STRING with POST that is not application/x-www-form-urlencoded

New submission from Daniel Klein : The documentation says "A form submitted via POST that also has a query string will contain both FieldStorage and MiniFieldStorage items." suggesting that I can have a query with bost a QUERY_STRING and POST parameters. The code backs this up most of the

[issue30356] test_mymanager_context() of test_multiprocessing_spawn: manager._process.exitcode=-15 on x86 Windows7 3.x

STINNER Victor added the comment: New changeset fbd7172325e6ce55b6d5d3d7603e4c1c8a219cb8 by Victor Stinner in branch 'master': bpo-30356: Fix test_mymanager_context() of multiprocessing (GH-7968) https://github.com/python/cpython/commit/fbd7172325e6ce55b6d5d3d7603e4c1c8a219cb8 --

[issue30356] test_mymanager_context() of test_multiprocessing_spawn: manager._process.exitcode=-15 on x86 Windows7 3.x

STINNER Victor added the comment: The bug can easily be reproduced on Linux using this change: diff --git a/Lib/multiprocessing/managers.py b/Lib/multiprocessing/managers.py index 04df26bac6..3d952407c2 100644 --- a/Lib/multiprocessing/managers.py +++ b/Lib/multiprocessing/managers.py @@

[issue30356] test_mymanager_context() of test_multiprocessing_spawn: manager._process.exitcode=-15 on x86 Windows7 3.x

miss-islington added the comment: New changeset a599323fc7661668a01e9fbb0d2369e62941bdf1 by Miss Islington (bot) in branch '3.6': bpo-30356: Fix test_mymanager_context() of multiprocessing (GH-7968) https://github.com/python/cpython/commit/a599323fc7661668a01e9fbb0d2369e62941bdf1

[issue21081] missing vietnamese codec TCVN 5712:1993 in Python

Tô Thị Mai added the comment: Theo tôi có thể hiểu, chúng là "tập hợp con" của nhau chỉ theo nghĩa là VN1 có bản đồ rộng nhất của các ký tự, nhưng điều này cũng trùng lặp một phần với các ký tự điều khiển C0 và C1 trong các trang mã ISO - có 139 nhân vật bổ sung! VN2 sau đó cho phép C0 và C1

[issue33968] os.makedirs and empty string

Emily Morehouse added the comment: The os.path conventions do follow, '' and '.' are not treated the same here either -- >>> os.path.exists('') False >>> os.path.exists('.') True >>> os.path.isdir('') False >>> os.path.isdir('.') True The only os.path function that I see as potentially

[issue25007] Add support of copy protocol to zlib compressors and decompressors

Serhiy Storchaka added the comment: New changeset d2cbfffc842b00b5257aa1c25dbcdeb456b6a249 by Serhiy Storchaka (Zackery Spytz) in branch 'master': bpo-25007: Add copy protocol support to zlib compressors and decompressors (GH-7940)

[issue25007] Add support of copy protocol to zlib compressors and decompressors

Serhiy Storchaka added the comment: Thank you for your contribution Zackery! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue33715] test_multiprocessing_spawn.test_wait_result() failed on x86 Windows7 3.x

STINNER Victor added the comment: Python 2.7 is not affected: it doesn't have the test. -- versions: +Python 3.6, Python 3.7 ___ Python tracker ___

[issue33715] test_multiprocessing_spawn.test_wait_result() failed on x86 Windows7 3.x

Change by miss-islington : -- pull_requests: +7584 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue30339] test_multiprocessing_main_handling: "RuntimeError: Timed out waiting for results" on x86 Windows7 3.x

Change by STINNER Victor : -- pull_requests: +7587 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33913] test_multiprocessing_spawn random failures on x86 Windows7 3.6

Change by STINNER Victor : -- pull_requests: +7586 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue31687] test_semaphore_tracker() of test_multiprocessing_spawn fails randomly (race condition?)

STINNER Victor added the comment: See also bpo-33613. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33613] test_multiprocessing_fork: test_semaphore_tracker_sigint() fails with -W error

STINNER Victor added the comment: See also bpo-31687. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue21081] missing vietnamese codec TCVN 5712:1993 in Python

STINNER Victor added the comment: Google Translate of msg320603 :-) As far as I can understand, we are "subset" of each other only in the sense that VN1 have extensive map of the characters, but it also overlaps partially with control characters C0 and C1 in the page ISO code - 139

[issue33983] unify types for lib2to3.pytree.Base.children

Change by John Reese : -- keywords: +patch pull_requests: +7588 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-list

[issue33715] test_multiprocessing_spawn.test_wait_result() failed on x86 Windows7 3.x

miss-islington added the comment: New changeset ecb1525e10bbde9a66d2d14a24ff7a7ddd9d3258 by Miss Islington (bot) in branch '3.7': bpo-33715: Fix multiprocessing test_wait_result() (GH-7971) https://github.com/python/cpython/commit/ecb1525e10bbde9a66d2d14a24ff7a7ddd9d3258 -- nosy:

[issue31546] PyOS_InputHook is not called when waiting for input() in Windows

Change by Thomas Caswell : -- keywords: +patch pull_requests: +7589 stage: -> patch review ___ Python tracker ___ ___

[issue33937] [3.6] test_socket: SendmsgSCTPStreamTest.testSendmsgTimeout() failed on Travis CI

Change by STINNER Victor : -- title: [3.6] test_socket: testSendmsgTimeout() failed on Travis CI -> [3.6] test_socket: SendmsgSCTPStreamTest.testSendmsgTimeout() failed on Travis CI ___ Python tracker

[issue32063] test_multiprocessing_forkserver failed with OSError: [Errno 48] Address already in use

STINNER Victor added the comment: I didn't see this failure recently. -- resolution: -> out of date stage: -> resolved status: open -> closed ___ Python tracker ___

[issue24033] Update _test_multiprocessing.py to use script helpers

STINNER Victor added the comment: Sorry but these patches have been lost in the huge database of open bugs and we forgot it. They have been written 3 years ago. Since that, Python moved to GitHub. If you are still interested to convert tests to script_helper, please open GitHub pull

[issue33715] test_multiprocessing_spawn.test_wait_result() failed on x86 Windows7 3.x

STINNER Victor added the comment: New changeset 492572715aa0f4ddab51f979f7f56465c762227c by Victor Stinner in branch 'master': bpo-33715: Fix multiprocessing test_wait_result() (GH-7971) https://github.com/python/cpython/commit/492572715aa0f4ddab51f979f7f56465c762227c --

[issue30339] test_multiprocessing_main_handling: "RuntimeError: Timed out waiting for results" on x86 Windows7 3.x

Change by miss-islington : -- pull_requests: +7583 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33913] test_multiprocessing_spawn random failures on x86 Windows7 3.6

Change by miss-islington : -- pull_requests: +7582 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33715] test_multiprocessing_spawn.test_wait_result() failed on x86 Windows7 3.x

Change by miss-islington : -- pull_requests: +7585 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue30356] test_mymanager_context() of test_multiprocessing_spawn: manager._process.exitcode=-15 on x86 Windows7 3.x

STINNER Victor added the comment: I fixed the test in 3.6, 3.7 and master branches. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue33983] unify types for lib2to3.pytree.Base.children

New submission from John Reese : When type checking applications using lib2to3, the difference in types for lib2to3.pytree.Base.children versus Node.children makes it difficult to accept both leaves and nodes and programatically work with child nodes/leaves. Base/Leaf both have `children`

[issue31463] test_multiprocessing_fork hangs test_subprocess

STINNER Victor added the comment: > This hangs reliably for me on master: > $ ./python -m test.regrtest test_multiprocessing_fork test_subprocess FYI right now, this command doesn't hang anymore. > ValueError: signal number 32 out of range This bug has been fixed by bpo-2. > Let's take

[issue30339] test_multiprocessing_main_handling: "RuntimeError: Timed out waiting for results" on x86 Windows7 3.x

miss-islington added the comment: New changeset 4b1d286ac06f32a5857af1b3141dd4127744b15b by Miss Islington (bot) in branch '3.7': bpo-33913: Fix test_multiprocessing_main_handling (GH-7972) https://github.com/python/cpython/commit/4b1d286ac06f32a5857af1b3141dd4127744b15b -- nosy:

[issue33913] test_multiprocessing_spawn random failures on x86 Windows7 3.6

miss-islington added the comment: New changeset 4b1d286ac06f32a5857af1b3141dd4127744b15b by Miss Islington (bot) in branch '3.7': bpo-33913: Fix test_multiprocessing_main_handling (GH-7972) https://github.com/python/cpython/commit/4b1d286ac06f32a5857af1b3141dd4127744b15b -- nosy:

[issue33913] test_multiprocessing_spawn random failures on x86 Windows7 3.6

STINNER Victor added the comment: I increased the timeout from 10 seconds to 1 minute in test_multiprocessing_main_handling in 3.6, 3.7 and master branches. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python

[issue33913] test_multiprocessing_spawn random failures on x86 Windows7 3.6

STINNER Victor added the comment: New changeset 1d06be8cc55715be8c32ec3b462adfb3a7839dfe by Victor Stinner in branch '3.6': bpo-33913: Fix test_multiprocessing_main_handling (GH-7972) (GH-7976) https://github.com/python/cpython/commit/1d06be8cc55715be8c32ec3b462adfb3a7839dfe --

[issue30339] test_multiprocessing_main_handling: "RuntimeError: Timed out waiting for results" on x86 Windows7 3.x

STINNER Victor added the comment: New changeset 1d06be8cc55715be8c32ec3b462adfb3a7839dfe by Victor Stinner in branch '3.6': bpo-33913: Fix test_multiprocessing_main_handling (GH-7972) (GH-7976) https://github.com/python/cpython/commit/1d06be8cc55715be8c32ec3b462adfb3a7839dfe --

[issue33715] test_multiprocessing_spawn.test_wait_result() failed on x86 Windows7 3.x

miss-islington added the comment: New changeset 404250ed65e01505c1ec7ea194804df160ce5400 by Miss Islington (bot) in branch '3.6': bpo-33715: Fix multiprocessing test_wait_result() (GH-7971) https://github.com/python/cpython/commit/404250ed65e01505c1ec7ea194804df160ce5400 --

[issue20934] test_multiprocessing is broken by design

STINNER Victor added the comment: I made different attempts, but at the end, we kept the status quo: some tests use an hardcoded timeout. When a test fails, I increase the timeout. That's not perfect, but nobody came up with a better approach, and it's not a deal. -- resolution: ->

[issue7060] test_multiprocessing dictionary changed size errors and hang

STINNER Victor added the comment: > RuntimeError: dictionary changed size during iteration I didn't see this bug the last 5 years, so I consider that the issue has been fixed in the meanwhile :-) -- resolution: out of date -> fixed status: open -> closed

[issue30339] test_multiprocessing_main_handling: "RuntimeError: Timed out waiting for results" on x86 Windows7 3.x

STINNER Victor added the comment: I increased timeout from 10 seconds to 1 minute in test_multiprocessing_main_handling, in 3.6, 3.7 and master branches. It should make test failures less likely on buildbots. -- dependencies: -test_timeout() of

[issue30339] test_multiprocessing_main_handling: "RuntimeError: Timed out waiting for results" on x86 Windows7 3.x

STINNER Victor added the comment: New changeset 64737e9ae2081e529935ecf07f44e89f362d1c4b by Victor Stinner in branch 'master': bpo-33913: Fix test_multiprocessing_main_handling (GH-7972) https://github.com/python/cpython/commit/64737e9ae2081e529935ecf07f44e89f362d1c4b --

[issue33913] test_multiprocessing_spawn random failures on x86 Windows7 3.6

STINNER Victor added the comment: New changeset 64737e9ae2081e529935ecf07f44e89f362d1c4b by Victor Stinner in branch 'master': bpo-33913: Fix test_multiprocessing_main_handling (GH-7972) https://github.com/python/cpython/commit/64737e9ae2081e529935ecf07f44e89f362d1c4b --

[issue33913] test_multiprocessing_spawn random failures on x86 Windows7 3.6

STINNER Victor added the comment: Python 2.7 is not affected: it doesn't have these tests. -- versions: +Python 3.7, Python 3.8 ___ Python tracker ___

[issue33966] test_multiprocessing_spawn.WithProcessesTestPool.test_traceback() leaks 4 handles on Windows

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

[issue33929] test_multiprocessing_spawn: WithProcessesTestProcess.test_many_processes() leaks 5 handles on Windows

STINNER Victor added the comment: I was decided to only fix the bug in the master branch, since it's a minor bug (leak a few handles in a rare case), whereas the backport can introduce regressions. https://github.com/python/cpython/pull/7921#issuecomment-400612321 The bug has been fixed in

[issue33939] Provide a robust O(1) mechanism to check for infinite iterators

Nick Coghlan added the comment: If C level iterator implementations in the standard library natively handled Ctrl-C (to cope with naive third party C level iterator consumers), and so did C level iterator consumers in the standard library (to cope with with naive third party C level

[issue33833] ProactorEventLoop raises AssertionError

STINNER Victor added the comment: > Sometimes when a socket transport under ProactorEventLoop is writing while > the peer closes the connection, asyncio logs an AssertionError. Would you mind to add an example of such error in this issue? -- ___

[issue33851] 3.7 regression: ast.get_docstring() for a node that lacks a docstring

Ned Deily added the comment: Fixed in 3.7.0. Thanks, everyone! -- priority: release blocker -> resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue33932] Calling Py_Initialize() twice now triggers a fatal error (Python 3.7)

Ned Deily added the comment: Fixed in 3.7.0. Thanks, everyone! -- priority: release blocker -> resolution: -> fixed status: open -> closed ___ Python tracker ___

[issue33833] ProactorEventLoop raises AssertionError

twisteroid ambassador added the comment: No problem. Running the attached test script on latest master, Windows 10 1803, several errors like this are logged: Exception in callback _ProactorBaseWritePipeTransport._loop_writing(<_OverlappedF...events.py:479>) handle: ) created at

[issue33929] test_multiprocessing_spawn: WithProcessesTestProcess.test_many_processes() leaks 5 handles on Windows

STINNER Victor added the comment: New changeset 0aab8660cdaa540730994afbce49a146dd779bce by Victor Stinner in branch 'master': bpo-33929: Fix regression in spawn_main() (#7962) https://github.com/python/cpython/commit/0aab8660cdaa540730994afbce49a146dd779bce --

[issue33932] Calling Py_Initialize() twice now triggers a fatal error (Python 3.7)

Nick Coghlan added the comment: https://github.com/python/cpython/pull/7967 amends the docs and adds the deprecation notices, but after taking another look at the way Victor's patch works, I'm thinking we may not need them: the *new* initialization API remains strict about the required

[issue27755] Retire DynOptionMenu with a ttk Combobox

Change by Mark Roseman : -- pull_requests: +7590 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue31647] asyncio: StreamWriter write_eof() after close raises mysterious AttributeError

Ned Deily added the comment: New changeset 28c6b94f26661aa6f2bf7d885332c66c85ae4c95 by Ned Deily in branch '3.6': Fix NEWS entry for bpo-31647 https://github.com/python/cpython/commit/28c6b94f26661aa6f2bf7d885332c66c85ae4c95 -- ___ Python

[issue33851] 3.7 regression: ast.get_docstring() for a node that lacks a docstring

Ned Deily added the comment: New changeset 235d0fb93cb456701ce24fad2bc307e9f0312d73 by Ned Deily (Miss Islington (bot)) in branch '3.7': bpo-33851: Fix ast.get_docstring() for a node that lacks a docstring. (GH-7682)

[issue33932] Calling Py_Initialize() twice now triggers a fatal error (Python 3.7)

Ned Deily added the comment: New changeset b940921a67fa33e8c8812aa3b7746161c2552c1d by Ned Deily (Miss Islington (bot)) in branch '3.7': bpo-33932: Calling Py_Initialize() twice does nothing (GH-7845) https://github.com/python/cpython/commit/b940921a67fa33e8c8812aa3b7746161c2552c1d

[issue29514] Add a test case that prevents magic number changes in minor releases

Ned Deily added the comment: New changeset 828351716ec436bfa174cfdb33def7ee7c0d2e63 by Ned Deily in branch '3.7': bpo-29514: Make magic number test work for candidates https://github.com/python/cpython/commit/828351716ec436bfa174cfdb33def7ee7c0d2e63 --

[issue33954] float.__format__('n') fails with _PyUnicode_CheckConsistency assertion error

STINNER Victor added the comment: Aha, the problem occurs when the thousands separator code point is greater than 255. On my Fedora 28 (glibc 2.27), it's U+202f: vstinner@apu$ ./python Python 3.8.0a0 (heads/master-dirty:492572715a, Jun 28 2018, 00:18:54) >>> import locale >>>

[issue33985] ContextVar does not have a "name" attribute

New submission from Rajiv Vijayakumar : Per PEP 567 and the contextvars documentation, I expected that a ContextVar would have a "name" read-only attribute. However I get an AttributeError when accessing ContextVar.name with 3.7.0rc1: > python Python 3.7.0rc1 (v3.7.0rc1:dfad352267, Jun 12

[issue33985] ContextVar does not have a "name" attribute

Yury Selivanov added the comment: Yeah, it seems that I forgot to implement ContextVars.name attribute. Will have a PR shortly. Expect to see this fixed in 3.7.1 in a couple of months. Adding Ned to the issue just in case. -- components: +Interpreter Core -Library (Lib) nosy:

[issue33985] ContextVar does not have a "name" attribute

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

[issue33914] test_gdb fails for Python 2.7.15

STINNER Victor added the comment: > Could not trace the inferior process. Your issue doesn't seem to be related to Python, but more to gdb in general. Can you try very basic commands like: $ gdb -args python3 -c pass (gdb) run Starting program: /usr/bin/python3 -c pass [Inferior 1 (process

[issue33984] test_multiprocessing_forkserver leaked [1, 2, 1] memory blocks on x86 Gentoo Refleaks 3.x

New submission from STINNER Victor : http://buildbot.python.org/all/#/builders/1/builds/267 1:47:06 load avg: 4.77 [161/417/1] test_multiprocessing_forkserver failed (16 min 32 sec) -- running: test_support (56 sec 282 ms) beginning 6 repetitions 123456 .. test_multiprocessing_forkserver

[issue33986] asyncio: Typo in documentation: BaseSubprocessTransport -> SubprocessTransport

Change by STINNER Victor : -- components: +asyncio -Documentation nosy: +asvetlov, yselivanov title: Typo: BaseSubprocessTransport -> SubprocessTransport -> asyncio: Typo in documentation: BaseSubprocessTransport -> SubprocessTransport ___ Python

[issue33986] Typo: BaseSubprocessTransport -> SubprocessTransport

New submission from Bumsik Kim : https://docs.python.org/3/library/asyncio-protocol.html#basesubprocesstransport I belive the doc has a wrong name "basesubprocesstransport" and it should be "Subprocesstransport". You can see this in the source code:

[issue33929] test_multiprocessing_spawn: WithProcessesTestProcess.test_many_processes() leaks 5 handles on Windows

Change by STINNER Victor : -- pull_requests: +7570 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33979] Display type of not JSON serializable object

New submission from Vincent Lefoulon : When we call `json.dumps` on a non JSON serializable object, we obtain an error: ``` TypeError: 4 is not JSON serializable ``` Here, 4 was actually a `numpy.int64` object and not a native int. But it is not explicit in the error message. We should

[issue33979] [Exception message] Display type of not JSON serializable object

Change by Vincent Lefoulon : -- title: Display type of not JSON serializable object -> [Exception message] Display type of not JSON serializable object ___ Python tracker ___

[issue33918] Hooking into pause/resume of iterators/coroutines

Liran Nuna added the comment: > That's still doable with contextvars. You just need a custom mock-like object > (or library) that stores its settings/state in a context variable. contextvars only work with asyncio, what about the iterator case? In addition, you can't possibly expect authors

[issue24546] sequence index bug in random.choice

Raymond Hettinger added the comment: Marking this as closed -- the original bug doesn't seem to be reproducible. See additional reasons and discussion in Issue #24567. -- resolution: -> works for me stage: -> resolved status: open -> closed ___

[issue24567] random.choice IndexError due to double-rounding

Raymond Hettinger added the comment: I concur with Tim. Marking the original bug as "won't fix" for the reasons that he listed. In a separate PR, I'll modify the last line random.choices() to be "return [population[bisect(cum_weights, random() * total, 0, hi)] for i in range(k)]". That

  1   2   >