[Python-Dev] Fighting the theoretical randomness of "is" on immutables

[PJ Eby]

On Mon, May 6, 2013 at 4:46 AM, Armin Rigo <arigo at tunes.org> wrote:
> This is clearly a language design issue though.  I can't really think
> of a use case that would break if we relax the requirement, but I
> might be wrong.  It seems to me that at most some modules like pickle
> which use id()-keyed dictionaries will fail to find some
> otherwise-identical objects, but would still work (even if tuples are
> "relaxed" in this way, you can't have cycles with only tuples).

I don't know if I've precisely understood the change you're proposing,
but I do know that in PEAK-Rules I use id() as an approximation for
"is" in order to build indexes of various "parameter is some_object"
conditions, for various "some_objects" and a given parameter.  The
rule engine takes id(parameter) at call time and then looks it up to
obtain a subset of applicable rules.  IIUC, this would require that
either "x is y" equates to "id(x)==id(y)", or else that there be some
way to determine in advance all the possible id(y)s that are now or
would ever be "is x", so they can be placed in the index.  Otherwise,
any use of an "is" condition would require a linear search of the
possibilities, as you could not rule out the possibility that a given
x was "is" to *some* y already in the index.

Of course, rules using "is" tend to be few and far between, outside of
some special cases, and their use with simple integers and strings
would be downright silly.  And on top of that, I'm not even sure
whether the "a <= b" notation you used was meant to signify "a implies
b" or "b implies a".  ;-)

But since you mentioned id()-keyed dictionaries and this is another
use of them that I know of, I figured I should at least throw it out
there for information's sake, regardless of which side of the issue it
lands on.  ;-)