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 Bob.Ziuchkovski
Recipients Arfrever, Bob.Ziuchkovski, Giovanni.Bajo, PaulMcMillan, ReneSac, Vlado.Boza, alex, arigo, benjamin.peterson, camara, christian.heimes, cvrebert, dmalcolm, gregory.p.smith, koniiiik, lemburg, mark.dickinson, sbermeister, serhiy.storchaka, vstinner, Łukasz.Rekucki
Date 2012-12-02.20:47:30
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1354481251.18.0.190611799123.issue14621@psf.upfronthosting.co.za>
In-reply-to
Content
Why not redefine -R to mean "use secure hashing algorithms for built-in types"?

When specified, use hashing algorithms that are secure against denial-of-service and other known attacks, at the possible expense of performance.  When not specified, use whatever hashing algorithms provide the most sensible defaults for every-day use (basically hash the way python currently hashes).

Secure hashing would apply not just to strings but to numeric and other types as well.  This would break the invariant of `x == y implies hash(x) == hash(y)` for numeric types that Mark mentioned.  However, that seems like an implementation detail that python users shouldn't rely upon.
History
Date User Action Args
2012-12-02 20:47:31Bob.Ziuchkovskisetrecipients: + Bob.Ziuchkovski, lemburg, arigo, gregory.p.smith, mark.dickinson, vstinner, christian.heimes, benjamin.peterson, Arfrever, alex, cvrebert, dmalcolm, Giovanni.Bajo, PaulMcMillan, serhiy.storchaka, Vlado.Boza, koniiiik, sbermeister, camara, Łukasz.Rekucki, ReneSac
2012-12-02 20:47:31Bob.Ziuchkovskisetmessageid: <1354481251.18.0.190611799123.issue14621@psf.upfronthosting.co.za>
2012-12-02 20:47:31Bob.Ziuchkovskilinkissue14621 messages
2012-12-02 20:47:30Bob.Ziuchkovskicreate