why () is () and [] is [] work in other way?

[Tim Delaney]

On 24 April 2012 11:08, Devin Jeanpierre <jeanpierreda at gmail.com> wrote:

> cache = {}
>
> def intern(x):
>     return cache.setdefault(x, x)
>
> Do we agree that A) this function works without using identity
> comparisons, and B) this function performs the task of interning?


Of course. I never claimed otherwise. It is however returning a reference
to a canonical object equal to the object being referred to by "x". In this
case, the canonical/standard form is "the first equal object that was put
into the cache".

cache = {}

def intern(x):
    return cache.setdefault(x, x)

>>> a = "x y"
>>> b = "x y"
>>> a is b
False
>>> id(a) == id(b)
False
>>> a = intern(a)
>>> b = intern(b)
>>> a is b
True
>>> id(a) == id(b)
True

My claim is that doing this automatically for all integers and/or strings
could lead to prohibitively-expensive performance characteristics, and done
wrong to prohibitively-expensive memory characteristics.

Now, you could declare "is" and == as the same operation for a whitelist of
types, but people have actual uses for being able to distinguish different
instances of equal immutable types. You shouldn't need to do it in your
normal day-to-day programming, but there are real uses for it.

cache = {}
> cachednan = float('nan')
>
> def intern(x):
>    try:
>        if math.isnan(x):
>            return cachednan
>    except TypeError:
>        pass
>    return cache.setdefault(x, x)
>
> I hope, again, that I've demonstrated that we don't need to
> canonicalize everything just to implement interning.


Except that the above is a canonicalisation function.

Tim Delaney
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20120424/084fb4fd/attachment-0001.html>