On 2/27/21 2:37 AM, Paul Moore wrote:
On Fri, 26 Feb 2021 at 23:36, Jim J. Jewett firstname.lastname@example.org wrote:
Whenever I've used except Exception or stronger, it was a sanitary barrier around code that might well do unpredictable or even stupid things. Adding a new kind of exception that I hadn't predicted -- including ExceptionGroup -- would certainly fit this description, and I want my driver loop to do what I told it. (Probably log an unexpected exception, and continue with the next record. I honestly don't even want a page, let alone a crash, because data from outside that barrier ... is often bad, and almost never in ways the on-call person can safely fix. And if they don't have time to find it in the logs, then it isn't a priority that week.)
This is my biggest concern. Disclaimer: I've yet to read the PEP, because async makes my head hurt, but I am aware of some of the background with Trio. Please take this as the perspective of someone thinking "I don't use async/await in my code, can I assume this doesn't affect me?"
I haven't read the PEP either. But I assume it could (should?) affect anyone managing multiple simultaneous /things/ in Python:
* async code, "fibers", "greenlets", Stackless "microthreads", "cooperative multitasking", or any other userspace mechanism where you manage multiple "threads" of execution with multiple stacks * code managing multiple OS-level threads * code managing multiple processes
It seems to me that any of those could raise multiple heterogeneous exceptions, and Python doesn't currently provide a mechanism to manage this situation. My dim understanding is that ExceptionGroup proposes a mechanism to handle exactly this thing.