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 | ncoghlan |
|---|---|
| Recipients | amaury.forgeotdarc, barry, eikeon, glyph, gvanrossum, jek, ncoghlan, rhettinger, schmir |
| Date | 2008年06月29日.08:34:32 |
| SpamBayes Score | 0.0032423593 |
| Marked as misclassified | No |
| Message-id | <1214728474.72.0.79643113404.issue2235@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
Well, I think I figured out why the __hash__ changes were backported from Py3k: without them, the existence of object.__hash__ makes the Hashable ABC completely useless (every newstyle class meets it). I see two options here. Option 1 is to revert the changes so __hash__ behave entirely as it did in 2.5 and also delete collections.Hashable from 2.6 (which may break other backported Py3k items). Doesn't seem like a particularly good idea. Option 2 is what I have implemented locally (and will be uploading soon): changing typeobject.c to allow Py_None to be stored in type method slots, and have it convert correctly to None at the Python level. Classes that don't want to inherit the default object.tp_hash implementation can then write "__hash__ = None" or "(hashfunc)Py_None" to block the inheritance. |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2008年06月29日 08:34:35 | ncoghlan | set | spambayes_score: 0.00324236 -> 0.0032423593 recipients: + ncoghlan, gvanrossum, barry, rhettinger, amaury.forgeotdarc, schmir, jek, eikeon, glyph |
| 2008年06月29日 08:34:34 | ncoghlan | set | spambayes_score: 0.00324236 -> 0.00324236 messageid: <1214728474.72.0.79643113404.issue2235@psf.upfronthosting.co.za> |
| 2008年06月29日 08:34:33 | ncoghlan | link | issue2235 messages |
| 2008年06月29日 08:34:32 | ncoghlan | create | |