Backward compatibility & Design considerations sections #20
Conversation
|
This PR has two commits - a small one to edit "backward compatibility" section. The paragraph I removed is now copied to #19, pending decision about whether to include asyncio integation in this PEP. The second commit is larger - it rewrites the "design considerations" section (why we did X instead of Y) as "rejected ideas" (why did we reject Y and do X instead). |
There was a problem hiding this comment.
I do wonder whether we need to say more about backwards compatibility. E.g. if someone has code that uses except Exception: and some library starts wrapping its exceptions in ExceptionGroup, that won't be caught. While that's really the library that's being backwards incompatible, I think we should call that out.
Good point, let me put that bit back. |
except_star.md
Outdated
| * Libraries that need to support older python versions will not be able to use | ||
| `except*`, and may need to handle `ExceptionGroup`s raised in user code through | ||
| the low-low_level `ExceptionGroup` APIs. |
There was a problem hiding this comment.
I think it's stronger. They may not raise ExceptionGroup.
There was a problem hiding this comment.
I think what @1st1 meant with this was that you can:
try:
userCode()
except BaseException as e:
if python_version >= 3.11:
if it's an exception group: do stuff to it
do whatever else
There was a problem hiding this comment.
Otherwise what is there to say? "if you need to support older python versions then you can't use the new features" ?
There was a problem hiding this comment.
Sorry, I didn't notice this bullet is specifically about older Python versions.
And when I think about the case I was concerned about more, that is just about calling out that raising ExceptionGroup from a library API may break applications that use that API and should thus be considered a new feature of the library. So I think we're good.
No description provided.