On Thu, 29 Nov 2018 at 14:12, Andrew Svetlov
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.
There was actually a PR to add compressions support to http.server but I closed it in the name of maintainability since http.server, as you said, isn't for production use so compression isn't critical. -Brett
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
wrote: On Thu, Nov 29, 2018 at 2:58 AM Andrew Svetlov
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
wrote: On Thu, Nov 29, 2018 at 6:27 AM Steven D'Aprano
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
_______________________________________________ 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.co... -- 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/brett%40python.org