Aur Saraf <[email protected]> added the comment:
I don't think HMAC of a file is a common enough use case to support, but I have
absolutely no problem conceding this point, the cost of supporting it is very
low.
I/O in C is a world of pain in general. In the specific case of `io.RawIOBase`
objects (non-buffered binary files) to my understanding it's not _that_
terrible (am I right? Does my I/O code work as-is?). To my understanding,
providing a fast path *just for this case* that calculates the hash without
taking the GIL for every chunk would be very nice to have for many use cases.
Now, we could just be happy with `file_digest()` having an `if` for
`isinstance(io.RawIOBase)` that chooses a fast code path silently. But since
non-buffered binary files are so hard to tell apart from other types of
file-like objects, as a user of this code I would like to have a way to say "I
want the fast path, please raise if I accidentally passed the wrong things and
got the regular path". We could have `file_digest('sha256', open(path, 'rb',
buffered=0), ensure_fast_io=True)`, but I think for this use case
`raw_file_digest('sha256', open(path, 'rb', buffered=0))` is cleaner.
In all other cases you just call `file_digest()`, probably get the Python I/O
and not the C I/O, and are still happy to have that loop written for you by
someone who knows what they're doing.
For the same reason I think the fast path should only support hash names and
not constructors/functions/etc', which would complicate it because
new-object-can-be-accessed-without-GIL wouldn't necessarily apply.
Does this make sense?
----------
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue45150>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
