Planning a Python Course for Beginners

[Marko Rauhamaa]

Chris Angelico <rosuav at gmail.com>:

> On Wed, Aug 9, 2017 at 10:00 PM, Marko Rauhamaa <marko at pacujo.net> wrote:
>> Chris Angelico <rosuav at gmail.com>:
>>
>>> Which means that its value won't change. That's what I said. Two
>>> things will be equal regardless of that metadata.
>>
>> In relational-database terms, your "value" is the primary key and
>> your "metadata" is the rest of the columns.
>
> I would say the primary key is the "identity" and the rest of the
> columns are the "value".

Your response illustrates why you and I are not yet on the same page on
this.

Typically, an object's equality is simply the "is" relation. The only
thing remaining for its usability as a key is a hash method. In fact,
just defining:

   def __hash__(self):
       return 0

will technically make any class applicable as a key or set member.

The interesting fields of the object (which you disparagingly referred
to as "metadata") don't need to participate in the calculation of the
hash. You ought to pick the maximal collection of immutable fields as a
basis of your hash, and you are all set (no pun intended).

> But if you're defining "value" solely by the PK, then you have to ask
> yourself what you're using this in a dictionary for - are you going to
> construct multiple objects representing the same underlying database
> row, and expect them to compare equal?

Let's leave the relational world and return to objects.

Really, the most obvious use case for hashed objects is their membership
in a set. For example:

    invitees = set(self.bff)
    invitees |= self.classmates()
    invitees |= self.relatives()

>>>> And Python doesn't enforce this in any way except for lists. That's
>>>> somewhat unfortunate since sometimes you really would like an
>>>> immutable (or rather, no-longer-mutable) list to act as a key.
>>>
>>> Then make a tuple out of it. Job done. You're trying to say that its
>>> value won't now change.
>>
>> Yeah, when there's a will, there's a way.
>
> I don't understand your comment. Do you mean that if someone wants to
> change it, s/he will?

No. I mean coercing lists to tuples can be quite a hefty operation. On
the other hand, so could hashing a list unless the value is memoized.

More importantly, tuple(collection) goes against the grain of what a
tuple is. Tuples are not collections. In particular, tuples in a given
role ordinarily have the same arity.


Marko