Message151966
> Jim Jewett <jimjjewett@gmail.com> added the comment:
>
> On Wed, Jan 25, 2012 at 1:05 PM, Antoine Pitrou <pitrou@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. |
|
Date |
User |
Action |
Args |
2012-01-25 19:13:09 | pitrou | set | recipients:
+ pitrou, lemburg, gvanrossum, tim.peters, barry, georg.brandl, terry.reedy, gregory.p.smith, jcea, mark.dickinson, vstinner, christian.heimes, benjamin.peterson, eric.araujo, grahamd, Arfrever, v+python, alex, zbysz, skrah, dmalcolm, gz, neologix, Arach, Mark.Shannon, eric.snow, Zhiping.Deng, Huzaifa.Sidhpurwala, Jim.Jewett, PaulMcMillan, fx5 |
2012-01-25 19:13:06 | pitrou | link | issue13703 messages |
2012-01-25 19:13:06 | pitrou | create | |
|