This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author neologix
Recipients ezio.melotti, nadeem.vawda, neologix, pitrou, serhiy.storchaka, skip.montanaro, tiwilliam
Date 2014-04-28.18:52:27
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAH_1eM3Ffgt+wvpOHze6mUD7Tubz4QZBwGs5u81fp2JrZbNc3g@mail.gmail.com>
In-reply-to <1398709321.48.0.427240583039.issue20962@psf.upfronthosting.co.za>
Content
> I don't think io.DEFAULT_BUFFER_SIZE makes much sense as a heuristic for the gzip module (or compressed files in general). Perhaps gzip should get its own DEFAULT_BUFFER_SIZE?

Do you mean from a namespace point of vue, or from a performance point of view?
Because this size is used to read/write from underlying the file
object, so using the io default would make sense, no?

Sure, it might not be optimal for compressed files, but I gues that
the optimal value is function of the compression-level block size and
many other factors which are just too varied to come up with a
reasonable heuristic.
History
Date User Action Args
2014-04-28 18:52:28neologixsetrecipients: + neologix, skip.montanaro, pitrou, nadeem.vawda, ezio.melotti, serhiy.storchaka, tiwilliam
2014-04-28 18:52:27neologixlinkissue20962 messages
2014-04-28 18:52:27neologixcreate