Re: What other languages use the same data model as Python?

From	Chris Torek <nospam@torek.net>
Newsgroups	comp.lang.python
Subject	Re: What other languages use the same data model as Python?
Date	2011-05-06 17:57 +0000
Organization	None of the Above
Message-ID	<iq1cpf021vl@news2.newsguy.com> (permalink)
References	<4dbd1dbf$0$29991$c3e8da3$5496439d@news.astraweb.com> <92fb5jFa2lU1@mid.individual.net> <4dc2c52e$0$10567$742ec2ed@news.sonic.net> <mailman.1196.1304613911.9059.python-list@python.org>

>>> John Nagle wrote:
>>>> A reasonable compromise would be that "is" is treated as "==" on
>>>> immutable objects.

(Note: I have no dog in this fight, I would be happy with a changed
"is" or with the current one -- leaky abstractions are fine with
me, provided I am told *when* they may -- or sometimes may not --
leak. :-) )

>> On 5/5/2011 3:06 AM, Gregory Ewing wrote:
>>> That wouldn't work for tuples, which can contain references
>>> to other objects that are not immutable.

>On Thu, May 5, 2011 at 9:41 AM, John Nagle <nagle@animats.com> wrote:
>> Such tuples are still identical, even if they
>> contain identical references to immutable objects.

In article <mailman.1196.1304613911.9059.python-list@python.org>
Ian Kelly  <ian.g.kelly@gmail.com> wrote:
>>>> a = (1, 2, [3, 4, 5])
>>>> b = (1, 2, [3, 4, 5])
>>>> a == b
>True
>>>> a is b  # Using the proposed definition
>True

I believe that John Nagle's proposal would make "a is b" false,
because while a and b are both immutable, they contain *different*
refernces to *mutable* objects (thus failing the "identical
references to immutable objects" part of the claim).

On the other hand, should one do:

    L = [3, 4, 5]
    a = (1, 2, L)
    b = (1, 2, L)

then "a is b" should (I say) be True under the proposal -- even
though they contain (identical) references to *mutable* objects.
Loosely speaking, we would define the "is" relation as:

    (x is y) if and only if
       (id(x) == id(y)
           or
           (x is immutable and y is immutable and
                (for all components xi and yi of x, xi is yi)))

In this case, even if the tuples "a" and "b" have different id()s,
we would find that both have an immutable type, and both have
components -- in this case, numbered, subscriptable tuple elements,
but instances of immutable class types like decimal.Decimal would
have dictionaries instead -- and thus we would recursively apply
the modified "is" definition to each element.  (For tuples, the
"all components" implies that the lengths must be equal; for class
instances, it implies that they need to have "is"-equal attributes,
etc.)

It's not entirely clear to me whether different immutable classes
(i.e., different types) but with identical everything-else should
compare equal under this modified "is".  I.e., today:

    $ cp /usr/lib/python2.?/decimal.py /tmp/deccopy.py
    $ python
    ...
    >>> sys.path.append('/tmp')
    >>> import decimal
    >>> import deccopy
    >>> x = decimal.Decimal('1')
    >>> y = deccopy.Decimal('1')
    >>> print x, y
    1 1
    >>> x == y
    False

and obviously "x is y" is currently False:

    >>> type(x)
    <class 'decimal.Decimal'>
    >>> type(y)
    <class 'deccopy.Decimal'>

However, even though the types differ, both x and y are immutable
[%] and obviously (because I copied the code) they have all the
same operations.  Since they were both created with the same starting
value, x and y will behave identically given identical treatment.
As such, it might be reasonable to ask that "x is y" be True
rather than False.

[% This is not at all obvious -- I have written an immutable class,
and it is pretty easy to accidentally mutate an instance inside
the class implementation.  There is nothing to prevent this in
CPython, at least.  If there were a minor bug in the decimal.Decimal
code such that x.invoke_bug() modified x, then x would *not* be
immutable, even though it is "intended to be".  (As far as I know
there are no such bugs in decimal.Decimal, it's just that I had
them in my "Money" class.)]
-- 
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W)  +1 801 277 2603
email: gmail (figure it out)      http://web.torek.net/torek/index.html

Thread