[issue44212] asyncio overrides signal handlers
Change by Francisco Demartino : -- keywords: +patch pull_requests: +24904 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26306 ___ Python tracker <https://bugs.python.org/issue44212> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44212] asyncio overrides signal handlers
Francisco Demartino added the comment: Looks like Roger Dahl also noted this on https://bugs.python.org/issue39765: > Second, set_signal_handler()[sic] silently and implicitly removes > corresponding handlers set with signal.signal(). [...] I think this should > be documented as well. (then has a linked PR that apparently doesn't address this second part) -- ___ Python tracker <https://bugs.python.org/issue44212> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44212] asyncio overrides signal handlers
New submission from Francisco Demartino : Hello, It looks like when asyncio sets up a signal handler, it forgets about the previous one (if any). Here's a patch (was about to create a PR but the default text brought me to bugs.python.org) https://github.com/franciscod/cpython/commit/bdac885b86fbb01d0d775f40c47870e48af5fa5b Tracked this down to the initial asyncio checkout, in commit 27b7c7ebf1039e96cac41b6330cf16b5632d9e49, a few commits before v3.4.0a4. Not sure if this is a bug but it surprised me. I would have expected that it registered an "additional" signal handler, or at least that my previously installed signal handler would be called afterwards. Also I'm not sure that it's a good idea to suddenly start running handlers that some current code might rely on not running, or have worked around this behaviour otherwise. Thanks, Francisco -- components: asyncio messages: 394174 nosy: Francisco Demartino, asvetlov, yselivanov priority: normal severity: normal status: open title: asyncio overrides signal handlers type: behavior versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue44212> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29630] REPL tab-completion triggers code execution
Francisco Demartino added the comment: Serhiy, Chris, thank you for your additional comments. They surely helped me understand why my solution to this "problem?" isn't that good (also I slept on it a bit and maybe that helped). I still ponder for a way to get autocompletion while guarranteeing no code will run, but a) any getter code is meant to run in that way, and b) it would somehow need to know the result of running that code without running it (Tricky, huh?). Thanks again for your patience. I feel enlightened :) -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue29630> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29630] REPL tab-completion triggers code execution
Francisco Demartino added the comment: > There is no way to safely inspect any Python object without triggering some > dunder functions like __getattr__, __getattribute__ or __dir__. But somehow inspect.getattr_static can do it? > Your change is not backwards compatible and makes auto-completion less useful. Why is it less useful? The only change is not executing property getters when showing completion options. It's removing a surprising code execution before the newline is received. Should CPython keep backwards compatibility of this execution-on-completion at the REPL? -- ___ Python tracker <http://bugs.python.org/issue29630> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29630] REPL tab-completion triggers code execution
Francisco Demartino added the comment: I've updated that branch and made a pull request (https://github.com/python/cpython/pull/248) I think this is a good compromise: inspect.getattr_static can tell if it's a property, and in that case we don't call getattr on it to prevent code execution on the completion. If it isn't a property, the current codepath is preserved. -- ___ Python tracker <http://bugs.python.org/issue29630> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29630] REPL tab-completion triggers code execution
Changes by Francisco Demartino : -- pull_requests: +213 status: pending -> open ___ Python tracker <http://bugs.python.org/issue29630> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29630] REPL tab-completion triggers code execution
Francisco Demartino added the comment: This branch (working on the PR) fixes it: https://github.com/franciscod/cpython/tree/bpo-29630 -- ___ Python tracker <http://bugs.python.org/issue29630> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29630] REPL tab-completion triggers code execution
New submission from Francisco Demartino: On the REPL, when autocompleting with the TAB key, getattr is called, potentially triggering code execution. This took me by surprise. Until you press RETURN, it should be pretty safe to go around autocompleting with certainty that you won't run any code. But that might be just my opinion. What do you think? -- components: Interpreter Core files: wat.py messages: 288420 nosy: Francisco Demartino priority: normal severity: normal status: open title: REPL tab-completion triggers code execution versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46662/wat.py ___ Python tracker <http://bugs.python.org/issue29630> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
