[issue31151] socketserver.ForkingMixIn.server_close() leaks zombie processes

Changes by STINNER Victor : -- title: test_socketserver: Warning -- reap_children() reaped child process -> socketserver.ForkingMixIn.server_close() leaks zombie processes ___ Python tracker __

[issue30391] test_threading_handled() and test_threading_not_handled() of test_socketserver hangs randomly on AMD64 FreeBSD 10.x Shared 3.6

STINNER Victor added the comment: I recently found two issues in socketserver: * bpo-31233: socketserver.ThreadingMixIn leaks running threads after server_close() * bpo-31151: socketserver.ForkingMixIn.server_close() leaks zombie processes Fixing these two issues is likely to help to fix this

[issue30983] eval frame rename in pep 0523 broke gdb's python extension

Łukasz Langa added the comment: The issue originally stems from the fact that a non-debug Python build with --enable-shared is inlining PyEval_EvalFrameEx into _PyEval_EvalFrameDefault. So, the patch should really become to *replace* discovering PyEval_EvalFrameEx with the discovery of _PyEval

[issue31234] Make support.threading_cleanup() stricter

STINNER Victor added the comment: test_threading: https://github.com/python/cpython/pull/3150 -- ___ Python tracker ___ ___ Python-bug

[issue31234] Make support.threading_cleanup() stricter

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

[issue31237] test_gdb disables 25% of tests in optimized builds

New submission from Łukasz Langa: We are skipping a lot of tests when optimizations are enabled (which essentially means: compiled without `--with-pydebug`). This seems overly aggressive since most Python users are using the gdb bindings with a non-debug build. I think we should have tests fo

[issue31237] test_gdb disables 25% of tests in optimized builds

STINNER Victor added the comment: Sadly, python-gdb fails to get required data for some commands, so python-gdb doesn't work fully on optimized builds. -- ___ Python tracker ___

[issue31238] pydoc: ServerThread.stop() leaves a dangling thread

New submission from STINNER Victor: When using https://github.com/python/cpython/pull/3138 I see that test_pydoc leaves a dangling thread. The bug comes from test_server() which uses pydoc ServerThread. ServerThread.stop() and test_pydoc don't join the thread. Moreover, ServerThread.docserver

[issue31238] pydoc: ServerThread.stop() leaves a dangling thread

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

[issue31238] pydoc: ServerThread.stop() leaves a dangling thread

STINNER Victor added the comment: This issue is similar to bpo-31151: socketserver ForkingMixIn.server_close() leaks zombie processes. -- ___ Python tracker ___

[issue31234] Make support.threading_cleanup() stricter

STINNER Victor added the comment: test_pydoc: see bpo-31238. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue31234] Make support.threading_cleanup() stricter

STINNER Victor added the comment: test_logging: see bpo-30830. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe

[issue31234] Make support.threading_cleanup() stricter

STINNER Victor added the comment: New changeset 3d284c081fc3042036adfe1bf2ce92c34d743b0b by Victor Stinner in branch 'master': bpo-31234: test_threading: fix ref cycle (#3150) https://github.com/python/cpython/commit/3d284c081fc3042036adfe1bf2ce92c34d743b0b -- ___

[issue31234] Make support.threading_cleanup() stricter

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

[issue30983] eval frame rename in pep 0523 broke gdb's python extension

Changes by Łukasz Langa : -- pull_requests: +3187 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.

[issue30983] eval frame rename in pep 0523 broke gdb's python extension

Changes by Łukasz Langa : -- pull_requests: +3187, 3188 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https:/

[issue31234] Make support.threading_cleanup() stricter

STINNER Victor added the comment: New changeset b50e7683acac36ff16e6c6c2c32d9a15e46b5174 by Victor Stinner in branch '3.6': bpo-31234: test_threading: fix ref cycle (#3150) (#3152) https://github.com/python/cpython/commit/b50e7683acac36ff16e6c6c2c32d9a15e46b5174 -- __

[issue31239] namedtuple comparison ignores types

New submission from Vlad Shcherbina: Toy example: >>> from collections import namedtuple >>> Rectangle = namedtuple('Rectangle', 'width height') >>> Ellipse = namedtuple('Ellipse', 'x_axis y_axis') >>> Rectangle(width=1, height=2) == Ellipse(x_axis=1, y_axis=2) True I understand this happens be

[issue31239] namedtuple comparison ignores types

Vlad Shcherbina added the comment: While we are at it, namedtuple inherits other operations that make no sense for fixed-length tuples: >>> Rectangle(width=1, height=2) * 3 (1, 2, 1, 2, 1, 2) >>> Rectangle(width=1, height=2) + Ellipse(x_axis=3, y_axis=4) (1, 2, 3, 4) But those are not so probl

[issue31206] IDLE, configdialog: Factor out HighPage class from ConfigDialog

Changes by Cheryl Sabella : -- pull_requests: +3189 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mai

[issue31205] IDLE, configdialog: Factor out KeysPage class from ConfigDialog

Changes by Cheryl Sabella : -- pull_requests: +3190 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mai

[issue31230] Define a general "asynchronous operation introspection" protocol

Nick Coghlan added the comment: I agree https://bugs.python.org/issue31197 is orthogonal - refactoring the current logic is useful regardless of what we do at the object attribute layer. Regarding __delegated_to__/__returns_to__, the reason I like *not* having "async" in the attribute names is

[issue31236] improve some error messages of min() and max()

Serhiy Storchaka added the comment: LGTM. -- components: +Interpreter Core -IO dependencies: +wrong error messages when too many kwargs are received nosy: +serhiy.storchaka stage: -> patch review type: behavior -> enhancement ___ Python tracker

[issue31232] Backport the new custom "print >> sys.stderr" error message?

Nick Coghlan added the comment: The condition we (mostly Serhiy) came up with for the check is actually kinda neat, since it's based on the value of the LHS and is hard to trigger accidentally: ``` >>> printf = print >>> print = 10 >>> print >> 1 5 >>> printf >> 1 Traceback (most recent call l

[issue30721] Show expected input for right shift operator usage in custom "print" error message

Changes by Nick Coghlan : -- pull_requests: +3192 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.

[issue31232] Backport the new custom "print >> sys.stderr" error message?

Changes by Nick Coghlan : -- pull_requests: +3191 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.

[issue14976] queue.Queue() is not reentrant, so signals and GC can cause deadlocks

Nick Coghlan added the comment: +1 for treating Queue.put() specifically as the case to be handled, as that's the mechanism that can be used to *avoid* running complex operations directly in __del__ methods and weakref callbacks. For testing purposes, the current deadlock can be reliably repro

<    1   2