> >> Modules/_lzmamodule.c:115: return _PyBytes_Resize(buf, size + BIGCHUNK);
> > This has quadratic performance.
> 
> Correct. I copied the algorithm from _io.FileIO, under the assumption
> that there was a reason for not using a simpler O(n log n) doubling
> strategy. Do you know of any reason for this? Or is it safe to ignore it?

I don't know, but I'd say it's safe to ignore it.
Maybe open a separate bug about that.
Generally we use a less-than-doubling strategy, to conserve memory (see
e.g. bytearray.c).

(note: it is O(n), not O(n log n))

> >> Modules/_lzmamodule.c:364: Py_BEGIN_ALLOW_THREADS
> > It seems that the Windows version at least is not thread-safe. If so, you
> > would need an LZMA lock when releasing the GIL.
> 
> Does the class need to be thread-safe, though? ISTM that there isn't any
> sensible use case for having two threads feeding data through the same
> compressor concurrently.

We certainly want to avoid crashes so, if that's what one risks from
using lzma from several threads, we should protect against it.