PEP-654: clarify that ExceptionGroup is not trivial to implement corr…

…ectly (#1894)

pep-0654.rst

@@ -98,7 +98,10 @@ Trio [2]_ is an example of a library that has made use of this technique in its
 ``MultiError`` [9]_ type. However, such an approach requires calling code to catch
 the container exception type, and then to inspect it to determine the types of
 errors that had occurred, extract the ones it wants to handle, and reraise the
-rest.
+rest. Furthermore, exceptions in Python have important information attached to
+their ``__traceback__``, ``__cause__`` and ``__context__`` fields, and
+designing a container type that preserves the integrity of this information
+requires care; it is not as simple as collecting exceptions into a set.
 
 Changes to the language are required in order to extend support for
 exception groups in the style of existing exception handling mechanisms. At
@@ -112,12 +115,12 @@ We considered whether it is possible to modify the semantics of ``except``
 for this purpose, in a backwards-compatible manner, and found that it is not.
 See the `Rejected Ideas`_ section for more on this.
 
-The purpose of this PEP, then, is to add the ``except*`` syntax for handling
-exception groups in the interpreter, which in turn requires that
-``ExceptionGroup`` is added as a builtin type. The desired semantics of
-``except*`` are sufficiently different from the current exception
-handling semantics that we are not proposing to modify the behavior of the
-``except`` keyword but rather to add the new ``except*`` syntax.
+The purpose of this PEP, then, is to add the ``ExceptionGroup`` builtin type
+and the ``except*`` syntax for handling exception groups in the interpreter.
+The desired semantics of ``except*`` are sufficiently different from the
+current exception handling semantics that we are not proposing to modify the
+behavior of the ``except`` keyword but rather to add the new ``except*``
+syntax.
 
 Our premise is that exception groups and ``except*`` will be used
 selectively, only when they are needed. We do not expect them to become