<div dir="ltr"><div dir="ltr">On Wed, Apr 14, 2021 at 6:20 PM Derek Homeier <<a href="mailto:derek@astro.physik.uni-goettingen.de">derek@astro.physik.uni-goettingen.de</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 14 Apr 2021, at 11:15 pm, Robert Kern <<a href="mailto:robert.kern@gmail.com" target="_blank">robert.kern@gmail.com</a>> wrote:<br>
> <br>
> On Wed, Apr 14, 2021 at 4:37 PM Joachim Wuttke <<a href="mailto:j.wuttke@fz-juelich.de" target="_blank">j.wuttke@fz-juelich.de</a>> wrote:<br>
> Regarding numpy, I'd propose a bolder measure:<br>
> To let savetxt(fname, X, ...) store exactly the same information in<br>
> compressed and uncompressed files, always invoke gzip with mtime = 0.<br>
> <br>
> I agree.<br>
>  <br>
I would caution though that relying on the checksum or similar of the compressed data still<br>
does not seem a very robust check of the data itself - the compressed file would still definitely<br>
change with any change in compression level, and quite possibly with changes in the<br>
linked compression library (perhaps even a simple version update).<br></blockquote><div><br></div><div>Sure, but in practice, that variability happens more rarely. In particular, I'm not going to see that variability when I'm re-running the same workflow with the same software versions inside of a system like DVC[1] that uses file hashes to determine which parts of the workflow need to get rerun. Whereas, I will see timestamp changes every time and thus invalidating the cache when it's irrelevant.</div><div><br></div><div><div>[1] <a href="https://dvc.org/">https://dvc.org/</a></div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Shouldn’t you better verify the data buffers themselves? Outside of Python, the lzma utility<br>
xzcmp for example allows binary comparison of the content of compressed files independently<br>
from the timestamp or even compression method, and it handles gzip and bzip2 files as well.<br></blockquote><div><br></div><div>We're often integrating with systems that only know how to compute hashes of files and doesn't try to dig into the semantics of the files any deeper. We're not looking to construct the most provably-correct cache, just make some pragmatic choices that will reduce false cache misses with systems that currently exist and enable *better*, if still imperfect, uses of those systems.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> I would like to follow up with a pull request, but I am unable to<br>
> find out how numpy.savetxt is invoking gzip.<br>
> <br>
> `savetxt` uses the abstractions in this module to invoke gzip when the filename calls for it:<br>
> <br>
> <a href="https://github.com/numpy/numpy/blob/main/numpy/lib/_datasource.py#L115" rel="noreferrer" target="_blank">https://github.com/numpy/numpy/blob/main/numpy/lib/_datasource.py#L115</a><br>
> <br>
One obstacle would be that this is setting gzip.open as _file_opener, which does not have the<br>
mtime option; getting this replaced with gzip.GzipFile to work in text mode would require to<br>
somehow replicate gzip.open’s io.TextIOWrapper wrapping of GzipFile.<br></blockquote><div><br></div><div>That should be easily doable.</div><div> </div></div>-- <br><div dir="ltr" class="gmail_signature">Robert Kern</div></div>