git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Python-Dev] Inclusion of lz4 bindings in stdlib?


Neither http.client nor http.server doesn't support compression
(gzip/compress/deflate) at all.
I doubt if we want to add this feature: for client better to use requests
or, well, aiohttp.
The same for servers: almost any production ready web server from PyPI
supports compression.

I don't insist on adding brotli to standard library.
There is officiall brotli library on PyPI from google, binary wheels are
provided.
Unfortunately installing from a tarball requires C++ compiler
On other hand writing a binding in pure C looks very easy.

On Thu, Nov 29, 2018 at 10:30 PM Gregory P. Smith <greg at krypto.org> wrote:

>
> On Thu, Nov 29, 2018 at 2:58 AM Andrew Svetlov <andrew.svetlov at gmail.com>
> wrote:
>
>> 5 cents about lz4 alternatives: Broli (mentioned above) is widely
>> supported by web.
>>
>> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Encoding
>> mentions it along with gzip and deflate methods.
>> I don't recall lz4 or Zstd metioning in this context.
>>
>> Both Chrome/Chromium and Firefox accepts it by default (didn't check
>> Microsoft products yet).
>>
>
> Acceptance by multiple popular browsers is a good reason to *also*
> propose brotli support in the stdlib. Though it'd probably make sense to
> actually _support_ Accept-Encoding based on available compression modules
> within the stdlib http.client (and potentially server) as a prerequisite
> for that reasoning.
> https://github.com/python/cpython/blob/master/Lib/http/client.py#L1168.
>
> -gps
>
>
>> P.S.
>> 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, have no update for the current state.
>>
>> On Thu, Nov 29, 2018 at 12:04 PM INADA Naoki <songofacandy at gmail.com>
>> wrote:
>>
>>> On Thu, Nov 29, 2018 at 6:27 AM Steven D'Aprano <steve at pearwood.info>
>>> wrote:
>>> >
>>> > On Wed, Nov 28, 2018 at 10:43:04AM -0800, Gregory P. Smith wrote:
>>> >
>>> > > PyPI makes getting more algorithms easy.
>>> >
>>> > Can we please stop over-generalising like this? PyPI makes getting
>>> > more algorithms easy for *SOME* people. (Sorry for shouting, but you
>>> > just pressed one of my buttons.)
>>>
>>> I don't think this is over-generalising.
>>>
>>> If "get it from PyPI" is not easy enough, why not adding hundreds of
>>> famous libraries?
>>> Because we can't maintain all of them well.
>>>
>>> When considering adding new format (not only compression, but also
>>> serialization like toml), I think it should be stable, widely used, and
>>> will
>>> be used widely for a long time.  If we want to use the format in Python
>>> core
>>> or Python stdlib, it's good reasoning too.  gzip and json are good
>>> example.
>>>
>>> When we say "we can use PyPI", it means "are there enough reasons
>>> make the package special enough to add to stdlib?"  We don't mean
>>> "everyone can use PyPI."
>>>
>>> Regards,
>>> --
>>> INADA Naoki  <songofacandy at gmail.com>
>>> _______________________________________________
>>> Python-Dev mailing list
>>> Python-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/python-dev
>>> Unsubscribe:
>>> https://mail.python.org/mailman/options/python-dev/andrew.svetlov%40gmail.com
>>>
>>
>>
>> --
>> Thanks,
>> Andrew Svetlov
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/greg%40krypto.org
>>
>

-- 
Thanks,
Andrew Svetlov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20181130/fd729c91/attachment-0001.html>