Zooko Wilcox-O'Hearn added the comment:
Well, read the thread!
http://mail.python.org/pipermail/python-dev/2009-June/090021.html
Basically just a couple of +1's, and a good suggestion to name it something
clearer than "crtime".
Please fix it!
--
nosy: +
Zooko Wilcox-O'Hearn added the comment:
Benjamin Peterson: what do you mean "hijack ctime"? I don't think I — or anyone
— has proposed anything that fits that description. Please be more specific.
My proposal in http://bugs.python.org/issue5720#msg85750 does
Zooko Wilcox-O'Hearn added the comment:
Benjamin: I'm sorry, I still don't understand. Do you think my proposal would
involve setting something named "ctime" to contain a value that didn't come
from the underlying stat "ctime"?
--
__
Zooko Wilcox-O'Hearn added the comment:
Aha! Mystery solved. I wouldn't say that you were stupid — I would say that
"crtime" is way too close to "ctime", and I strongly agree with the suggestion
(http://mail.python.org/pipermail/python-dev/2009-June/090026.html
New submission from Zooko Wilcox-O'Hearn:
(Disclosure: I'm one of the authors of BLAKE2.)
Please include BLAKE2 in hashlib. It well-suited for hashing long inputs (e.g.
files), because it is substantially faster than SHA-3, SHA-2, SHA-1, or MD5
while also being safer than SHA-2, SHA
Zooko Wilcox-O'Hearn added the comment:
Oh, just to be clear, I didn't mean to imply that BLAKE2 is _less_ safe than
SHA-3. My best estimate is that BLAKE2 and SHA-3 are equivalently safe, and
that either of them is safer than SHA-2, SHA
