[Python-Dev] Pre-PEP: Mutable keys in dictionaries
Just van Rossum
just@letterror.com
Thu, 6 Feb 2003 20:42:59 +0100
[JvR]
> > When implemented in C in dictobject.c, this would add no overhead
> > for the "normal" case (when keys _are_ directly hashable).
[GvR]
> I have a small doubt about this claim. Inserting code into
> PyDict_SetItem(), even if it is normally never executed, may reduce
> code locality and hence cause the code to miss the cache more often
> than before. This *may* be addressed by rearranging the code, but
> there's a limit to that.
Ok, so this will need to be addressed somehow.
> I have a countersuggestion.
>
> Could you do this as a subclass of dict? A subclass in Python would
> be inefficient, but might still be good enough for your second use
> case (the ObjC bridge). If not, a subclass in Python might be
> feasible -- it would be a little bit more work than integrating it
> into dictobject.c, but you have a lot less convincing to do, and you
> can even get it to work with Python 2.2.
But it doesn't solve our problem. We have no control over what
dictionaries are used, either by our users directly or by the Python
library they use. We _do_ have control over the keys that are causing
troubles: our main problem is that we cannot rely on NSString instances
to be immutable, yet we need the ability to use them as keys in
(regular) dicts, just as if they were Python strings.
Just