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 epicfaace
Recipients belopolsky, benjamin.peterson, christian.heimes, dmalcolm, epicfaace, lemburg, mark.dickinson, rhettinger, serhiy.storchaka, tim.peters, vstinner
Date 2019-08-23.13:54:35
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1566568475.91.0.106571160861.issue29535@roundup.psfhosted.org>
In-reply-to
Content
Makes sense, thanks for the explanation. The risk is that if there is code that, say, converts a POST dictionary to a dictionary with numeric keys, that code could be exploited. Creating a non-deterministic hash doesn't necessarily preclude hash(x) = x for a small enough x either. 

Given that other libraries (NumPy, etc.) rely on the numeric hash staying the way it is, it makes sense to keep it as it is. Since when did something that seems at first glance to be an implementation detail become more like a backwards-incompatible API, though? (For example, the implementation of the numeric hash was changed without any backwards-compatibility issues in https://bugs.python.org/issue14621). Might there be a better way to clarify this distinction for other features in Python?

I think the way forward for this patch is to keep the datetime hash as it is, and remove "datetime" in the parts of documentation that enumerate which data types have non-deterministic hashes.
History
Date User Action Args
2019-08-23 13:54:35epicfaacesetrecipients: + epicfaace, lemburg, tim.peters, rhettinger, mark.dickinson, belopolsky, vstinner, christian.heimes, benjamin.peterson, dmalcolm, serhiy.storchaka
2019-08-23 13:54:35epicfaacesetmessageid: <1566568475.91.0.106571160861.issue29535@roundup.psfhosted.org>
2019-08-23 13:54:35epicfaacelinkissue29535 messages
2019-08-23 13:54:35epicfaacecreate