Antoine Pitrou <pit...@free.fr> added the comment: > Jim Jewett <jimjjew...@gmail.com> added the comment: > > On Wed, Jan 25, 2012 at 1:05 PM, Antoine Pitrou <pit...@free.fr> > added the comment: > > > It looks like that approach will break any non-builtin type (in either C > > or Python) which can compare equal to bytes or str objects. If that's > > the case, then I think the likelihood of acceptance is close to zero. > > (1) Isn't that true of *any* patch that changes hashing? (Thus the > PYTHONHASHSEED=0 escape hatch.)
If a third-party type wants to compare equal to bytes or str objects, its __hash__ method will usually end up calling hash() on the equivalent bytes/str object. That's especially true for Python types (I don't think anyone wants to re-implement a slow str-alike hash in pure Python). > (2) I think it would still work for the lookdict_string (or > lookdict_unicode) case ... which is the normal case, and also where > most vulnerabilities should appear. It would probably still work indeed. > (3) If the alternate hash is needed for non-string keys, there is no > perfect resolution, but I suppose you could get closer with > > if obj == str(obj): > newhash=hash(str(obj)) That may be slowing down things quite a bit. It looks correct though. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue13703> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
