On Thu, 29 Nov 2018 at 11:00, Andrew Svetlov wrote:
> I worked with lz4 python binding a year ago.
> It sometimes crashed to core dump when used in multithreaded environment (we
> used to run compressor/decompresson with asyncio by loop.run_in_executor()
> call).
> I hope the bug is fixed now, h
On Thu, 29 Nov 2018 at 09:13, Gregory P. Smith wrote:
> Q: Are there other popular alternatives to fill that niche that we should
> strongly consider instead or as well?
>
> 5 years ago the answer would've been Snappy. 15 years ago the answer
> would've been LZO.
>
Today LZ4 hits a sweet spot
On Wed, 28 Nov 2018 at 18:57, Antoine Pitrou wrote:
>
> On Wed, 28 Nov 2018 10:43:04 -0800
> "Gregory P. Smith" wrote:
[snip]
> > I don't think adding lz4 to the stdlib is worthwhile. It isn't required
> > for core functionality as zlib is (lowest common denominator zip support).
>
> Actually, i
Hi,
I have for sometime maintained the Python bindings to the LZ4
compression library[0, 1]:
I am wondering if there is interest in having these bindings move to
the standard library to sit alongside the gzip, lzma etc bindings?
Obviously the code would need to be modified to fit the coding
guide
Hello,
I am not sure if this is expected behaviour, or a bug.
In a C extension module, if I create and return an empty bytes object like this:
val = PyBytes_FromStringAndSize (NULL, 20);
Py_SIZE(val) = 0;
Then from the Python interpreter's perspective:
isinstance(val, bytes) return
