address some of the suggestions and feedback

Signed-off-by: Pablo Galindo <[email protected]>

peps/pep-0760.rst

@@ -17,7 +17,6 @@ handling and mask important errors. This PEP suggests requiring explicit
 exception types in all except clauses, promoting more precise and intentional
 error handling.
 
-
 Motivation
 ==========
 
@@ -51,6 +50,19 @@ precise error handling:
    except Exception as e:
        handle_expected_error(e)
 
+Another view of this problem is that bare except handlers are ambiguous
+regarding the intended handling of terminating exceptions, as the intention
+could have been either:
+
+* Only catch non-terminating exceptions (``except Exception:``). If this was the
+  intention, using a bare ``except:`` is an outright bug, since that isn't what it
+  means.
+* Catch all exceptions, including terminating ones (``except BaseException:``).
+  using bare ``except:`` here is at least correct, but readers need to check
+  to be sure it isn't an instance of the first case.
+
+Since both possible intentions have available unambiguous spellings, the
+ambiguous form is redundant and that's why we propose to disallow it.
 
 Rationale
 =========
@@ -104,7 +116,9 @@ This change is not backwards compatible. Existing code that uses bare ``except:`
 clauses will need to be modified. To ease the transition:
 
 1. A deprecation warning will be issued for bare except clauses in Python 3.14.
-2. The syntax will be fully disallowed in Python 3.15.
+2. The syntax will be fully disallowed in Python 3.17.
+3. A ``from __future__ import strict_excepts`` will be provided to invalidate bare
+   except handlers in earlier versions of Python.
 
 A tool will be provided to automatically update code to replace bare ``except:``
 with ``except BaseException:``.
@@ -143,6 +157,35 @@ now enforced by the language. The following points should be emphasized:
 Documentation should guide common exception hierarchies and how to choose
 appropriate exception types to catch.
 
+Rejected ideas
+==============
+
+* There are genuine cases where the use of bare ``except:`` handlers are correct. one
+  of the examples that have been raised from Mailman [8]_ involves handling transactions
+  in the face of any exception:
+
+   .. code-block:: python
+
+       @contextmanager
+       def transaction():
+           """Context manager for ensuring the transaction is complete."""
+           try:
+               yield
+           except:
+               config.db.abort()
+               raise
+           else:
+               config.db.commit()
+
+  This code guarantees that no matter what exception occurs, any open
+  transaction will be aborted, while in the successful condition, the
+  transaction will be committed. 
+
+  We do believe that although there are cases such like this one where
+  bare ``except:`` handlers are correct, it would be better to actually
+  be explicit and use ``except BaseException:`` for the reasons indicated
+  in the "Motivation" section.
+
 
 Copyright
 =========
@@ -157,4 +200,5 @@ CC0-1.0-Universal license, whichever is more permissive.
 .. [5] https://chromium.googlesource.com/chromiumos/platform/factory/+/HEAD/CODING_STYLE.md#Avoid-bare_except
 .. [6] https://4.docs.plone.org/develop/plone-coredev/style.html#concrete-rules
 .. [7] https://docs.openedx.org/en/latest/developers/references/developer_guide/style_guides/python-guidelines.html
+.. [8] https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/database/transaction.py#L27