Itamar has written up a super interesting proposal for how we might make Failure immutable, and thereby some of its use-cases somewhat more performant: https://github.com/twisted/twisted/issues/12111
First I just wanted to point to this as a great example of how to write up a proposal, it's almost to a PEP level of detail.
I don't think we need any particular input on the discussion, but this is a subtle and core area of the API, so it would be easy for me to miss an area where feedback would be useful. In any case, if you're a heavy user of Twisted you might be interested in this discussion. If we do it right, it shouldn't really require applications to do much, but if you have code that introspects Failures or their tracebacks for development tooling, it's something you might want to think about any changes you might need to make before the release which includes it.
-g
On behalf of the Twisted contributors I announce the release of Twisted 24.3.0 (the release formerly known as 24.2.0, before too much time passed.)
The notable changes are:
• A variety of small bug fixes.
• A performance improvement when doing many very small writes over TLS.
• Fix breakage with latest PyPy release.
The release changes can be seen at https://github.com/twisted/twisted/releases/tag/twisted-24.3.0
Wheels for the release are available on PyPI.
Many thanks to everyone who worked on this release!
—Itamar
