Asp Forum - object identity and hashing

Aaron Brady

2/25/2008 1:40:00 AM

Can someone explain this?

>>> a= {}
>>> a[(3,)]= 0
>>> (3,) in a
True
>>> (3,) is (3,)
False

9 Answers

Jeff Schwab

2/25/2008 1:58:00 AM

castironpi@gmail.com wrote:
> Can someone explain this?
>
>>>> a= {}

Create an empty dict and bind it to the name a.

>>>> a[(3,)]= 0

Set the key/value pair (3,):0 to the dict.

>>>> (3,) in a

Is (3,) one of the keys in the dict?

> True

Yes, it is.

>>>> (3,) is (3,)

Create two separate tuples (that happen to be equivalent). Are they the
same object?

> False

No, they are not.

Every time you write (3,), you are potentially creating a new object.
These objects have equal values (and hash codes), so they are
interchangeable for purposes of keying a dict.

Aaron Brady

2/25/2008 2:11:00 AM

On Feb 24, 7:58 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
> castiro...@gmail.com wrote:
> > Can someone explain this?
>
> >>>> a= {}
>
> Create an empty dict and bind it to the name a.
>
> >>>> a[(3,)]= 0
>
> Set the key/value pair (3,):0 to the dict.
>
> >>>> (3,) in a
>
> Is (3,) one of the keys in the dict?
>
> > True
>
> Yes, it is.
>
> >>>> (3,) is (3,)
>
> Create two separate tuples (that happen to be equivalent). Are they the
> same object?
>
> > False
>
> No, they are not.
>
> Every time you write (3,), you are potentially creating a new object.
> These objects have equal values (and hash codes), so they are
> interchangeable for purposes of keying a dict.

I see. You stated,

> Is (3,) one of the keys in the dict?
>
> > True
>
> Yes, it is.

It isn't, but it does equal a key that's already in the dict.

George Sakkis

2/25/2008 3:29:00 AM

On Feb 24, 9:11 pm, castiro...@gmail.com wrote:
> On Feb 24, 7:58 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
>
>
>
> > castiro...@gmail.com wrote:
> > > Can someone explain this?
>
> > >>>> a= {}
>
> > Create an empty dict and bind it to the name a.
>
> > >>>> a[(3,)]= 0
>
> > Set the key/value pair (3,):0 to the dict.
>
> > >>>> (3,) in a
>
> > Is (3,) one of the keys in the dict?
>
> > > True
>
> > Yes, it is.
>
> > >>>> (3,) is (3,)
>
> > Create two separate tuples (that happen to be equivalent). Are they the
> > same object?
>
> > > False
>
> > No, they are not.
>
> > Every time you write (3,), you are potentially creating a new object.
> > These objects have equal values (and hash codes), so they are
> > interchangeable for purposes of keying a dict.
>
> I see. You stated,
>
> > Is (3,) one of the keys in the dict?
>
> > > True
>
> > Yes, it is.
>
> It isn't, but it does equal a key that's already in the dict.

Right, dict lookup depends on object hashing (__hash__) and equality
(__eq__), not identity. There are legitimate cases where lookup should
be based on identity [1], but they are far less common than those
based on equality.

George

[1] http://www.martinfowler.com/eaaCatalog/identi...

Aaron Brady

2/25/2008 4:03:00 AM

On Feb 24, 9:28 pm, George Sakkis <george.sak...@gmail.com> wrote:
> On Feb 24, 9:11 pm, castiro...@gmail.com wrote:
>
>
>
>
>
> > On Feb 24, 7:58 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
>
> > > castiro...@gmail.com wrote:
> > > > Can someone explain this?
>
> > > >>>> a= {}
>
> > > Create an empty dict and bind it to the name a.
>
> > > >>>> a[(3,)]= 0
>
> > > Set the key/value pair (3,):0 to the dict.
>
> > > >>>> (3,) in a
>
> > > Is (3,) one of the keys in the dict?
>
> > > > True
>
> > > Yes, it is.
>
> > > >>>> (3,) is (3,)
>
> > > Create two separate tuples (that happen to be equivalent). Are they the
> > > same object?
>
> > > > False
>
> > > No, they are not.
>
> > > Every time you write (3,), you are potentially creating a new object.
> > > These objects have equal values (and hash codes), so they are
> > > interchangeable for purposes of keying a dict.
>
> > I see. You stated,
>
> > > Is (3,) one of the keys in the dict?
>
> > > > True
>
> > > Yes, it is.
>
> > It isn't, but it does equal a key that's already in the dict.
>
> Right, dict lookup depends on object hashing (__hash__) and equality
> (__eq__), not identity. There are legitimate cases where lookup should
> be based on identity [1], but they are far less common than those
> based on equality.
>
> George
>
> [1]http://www.martinfowler.com/eaaCatalog/identit... Hide quoted text -
>
> - Show quoted text -

[1] illustrates a case in which 'a is a' returns False, and in the
other corner of the DeMorgan table, there is 'a is b' returns True for
'a == b' False.

Steve Holden

2/25/2008 2:22:00 PM

castironpi@gmail.com wrote:
> On Feb 24, 9:28 pm, George Sakkis <george.sak...@gmail.com> wrote:
>> On Feb 24, 9:11 pm, castiro...@gmail.com wrote:
>>
>>
>>
>>
>>
>>> On Feb 24, 7:58 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
>>>> castiro...@gmail.com wrote:
>>>>> Can someone explain this?
>>>>>>>> a= {}
>>>> Create an empty dict and bind it to the name a.
>>>>>>>> a[(3,)]= 0
>>>> Set the key/value pair (3,):0 to the dict.
>>>>>>>> (3,) in a
>>>> Is (3,) one of the keys in the dict?
>>>>> True
>>>> Yes, it is.
>>>>>>>> (3,) is (3,)
>>>> Create two separate tuples (that happen to be equivalent). Are they the
>>>> same object?
>>>>> False
>>>> No, they are not.
>>>> Every time you write (3,), you are potentially creating a new object.
>>>> These objects have equal values (and hash codes), so they are
>>>> interchangeable for purposes of keying a dict.
>>> I see. You stated,
>>>> Is (3,) one of the keys in the dict?
>>>>> True
>>>> Yes, it is.
>>> It isn't, but it does equal a key that's already in the dict.
>> Right, dict lookup depends on object hashing (__hash__) and equality
>> (__eq__), not identity. There are legitimate cases where lookup should
>> be based on identity [1], but they are far less common than those
>> based on equality.
>>
>> George
>>
>> [1]http://www.martinfowler.com/eaaCatalog/identit... Hide quoted text -
>>
>> - Show quoted text -
>
> [1] illustrates a case in which 'a is a' returns False, and in the
> other corner of the DeMorgan table, there is 'a is b' returns True for
> 'a == b' False.
But this doesn't tell you anything about Python except that it's
flexible enough to construct counter-intuitive classes.

Everything you have been told is true for the normal cases you will come
across in everyday usage. If you want to play in the obscure corners of
the language that's fine, but don't try and treat them as mainstream.

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.hold...

Aaron Brady

2/25/2008 3:07:00 PM

> But this doesn't tell you anything about Python except that it's
> flexible enough to construct counter-intuitive classes.
>
> Everything you have been told is true for the normal cases you will come
> across in everyday usage. If you want to play in the obscure corners of
> the language that's fine, but don't try and treat them as mainstream.

Good point.

Jeff Schwab

2/26/2008 1:44:00 AM

castironpi@gmail.com wrote:
> On Feb 24, 9:28 pm, George Sakkis <george.sak...@gmail.com> wrote:
>>
>> [1]http://www.martinfowler.com/eaaCatalog/identi...
>
> [1] illustrates a case in which 'a is a' returns False, and in the
> other corner of the DeMorgan table, there is 'a is b' returns True for
> 'a == b' False.

What is the 'a is a' == False case? I don't see anything like that
illustrated on the Identity Map page. Is it "P of EAA?"

Aaron Brady

2/27/2008 12:36:00 PM

On Feb 25, 7:44 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
> castiro...@gmail.com wrote:
> > On Feb 24, 9:28 pm, George Sakkis <george.sak...@gmail.com> wrote:
>
> >> [1]http://www.martinfowler.com/eaaCatalog/identi...
>
> > [1] illustrates a case in which 'a is a' returns False, and in the
> > other corner of the DeMorgan table, there is 'a is b' returns True for
> > 'a == b' False.
>
> What is the 'a is a' == False case? I don't see anything like that
> illustrated on the Identity Map page. Is it "P of EAA?"

Good point. I don't know. Just another logical possibility to go in
the 1% of cases. What is P of EAA?

Also, notice: For the list and tuple types, x in y is true if and only
if there exists an index i such that x == y[i] is true-- from the
docs.

And:>>> 'abc' is 'abc'
True

Rich Rostrom

7/1/2014 8:15:00 PM

Rich Rostrom <rrostrom.21stcentury@rcn.com> wrote:

> As to the effects on Germany - Wilhelm's
> brother would succeed instead.

Whoops! I am wrong, wrong, WRONG!!!

The incident with Wilhelm was in 1891. (He
was already Kaiser since 1888.) And he had
_six_ sons born and living at that time.

Wilhelm's eldest son, Kronprinz Wilhelm, was
nine years old.

So Little Willy succeeds, with either his
mother or his eldest uncle Heinrich as
Regent.

Neither Little Willy nor Heinrich will
be as assertive as OTL Wilhelm. Neither
will dare to challenge Bismarck, who will
probably stay in office till he dies.

Regent Heinrich may support Tirpitz's
naval program more than Wilhelm.

Otherwise, hard to say.
--
The real Velvet Revolution - and the would-be hijacker.

http://originalvelvetrevo...

comp.lang.python

object identity and hashing

Aaron Brady

Jeff Schwab

Aaron Brady

George Sakkis

Aaron Brady

Steve Holden

Aaron Brady

Jeff Schwab

Aaron Brady

Rich Rostrom

x Login to ForumsZone