Is 'everything' a refrence or isn't it?

Steven D'Aprano steve at REMOVETHIScyber.com.au
Sun Jan 15 09:27:35 EST 2006


On Sun, 15 Jan 2006 12:14:16 +0100, Fredrik Lundh wrote:

>> Do two instances of Empty have the same value, or is the question
>> meaningless?
> 
> Things are a bit mixed up wrt. old-style classes (because they're
> implemented in terms of true objects), but if you make that
> 
>     >>> class Empty(object):
>     ...     __slots__ = []
>     ...
> 
> it should be clear that instances of this class have no value (or if you
> prefer, the set of values is empty for all instances), and cannot have
> one either.

But that's the thing, it isn't clear to me at all that they have no value.
Does the empty string have a value? I would say yes. How about {} and []?
Again, I would say yes. So why do None and Empty() have no value?

It took mathematicians centuries to stop arguing about whether 0 is a
number or not, and then they argued whether or not 1 is a number. And
then when they settled that both 0 and 1 are numbers, they argued
whether the empty set counted as a set or not. So I'm not surprised that
we don't see eye-to-eye here.

I think part of the reason is that you are thinking at one abstract level,
where objects have a type, an identity, and "everything else", and you
DEFINE that "everything else" as "value". By that definition, if there is
nothing else, then there is no value. I can understand that, but I also
think that there is a different sense of "value" for which it makes sense
to include type and/or identity as part of the value. The alternative, it
seems to me, is to conclude that empty strings, dicts, lists and tuples
all are equally valueless, and I don't think that is a good idea.

The downside of my definition of "value" is that it is fuzzy and depends
on context. Often we want to exclude type (so that 1 and 1.0 have the
same value), we almost always want to exclude identity (so that [1,2] and
[1]+[2] have the same value), but there are enough exceptions to make
things interesting.



-- 
Steven.




More information about the Python-list mailing list