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 <g...@krypto.org> wrote: > > On Thu, Nov 29, 2018 at 2:58 AM Andrew Svetlov <andrew.svet...@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 <songofaca...@gmail.com> >> wrote: >> >>> On Thu, Nov 29, 2018 at 6:27 AM Steven D'Aprano <st...@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 <songofaca...@gmail.com> >>> _______________________________________________ >>> Python-Dev mailing list >>> Python-Dev@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@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
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
