Official definition of call-by-value (Re: Finding the instance reference...)

[Steven D'Aprano]

On Sun, 16 Nov 2008 04:12:53 -0500, Derek Martin wrote:

> On Sun, Nov 16, 2008 at 06:06:20AM +0000, Steven D'Aprano wrote:
>> >>> * Do all objects have values? (Ignore the Python
>> >>>  docs if necessary.)
>> >>
>> >> If one allows null values, I am current thinking yes.
>> > 
>> > I don't see a difference between a "null value" and not having a
>> > value.
>> 
> [...]
>> It wasn't until the fifth century C.E. that Indian mathematicians
>> invented the concept of zero, and it took many centuries for the idea
>> to get to Europe via the Arabs.
> 
> I think he meant None...  Or at least, I personally see a distinction
> between zero and None (and so do the Python docs).

Of course zero is different from None. For starters, you can't add 1 to 
None.


> Zero is a value,

Yes it is.

> whereas None is specifically intended to denote the lack of any value.

None is intended to be *interpreted* by the programmer as the lack of any 
other value. That's what the null object pattern is. MySql has a Null, C 
has null pointers, Pascal has the nil pointer, Python has None, integer 
mathematics has 0, matrix mathematics has any number of identity matrices 
under addition, the ASCII character set has nul... in some older 
programming frameworks, numbers like 9999 or -1 are used. (I remember a 
bug in "Arrow Accounting" that occurred because empty integer fields were 
set to 99 or similar.) 


> I
> would, FWIW, only make such a distinction in the context of a computer
> program...  Clearly in mathematics and elsewhere, zero is the lack of a
> value (it is the value of nothingness).

Contradicting your claim above, not to mention about five hundred years 
of European mathematics and about 1500 years of Indian mathematics.

 
>> "The value of the object is the number of sheep in the paddock, unless
>> the number of sheep is zero, in which case the object has no value..."
>> which is needlessly complicated.
> 
> For conversation, yes... but technically correct.

No, I would say the value of the object is the number of sheep, 
regardless of whether that number is 0 or 1 or 99.

 
>> I say that 0 is a perfectly fine value. So is None, [], {}, and any
>> other null-value. I recommend you don't complicate and confuse matters
>> by trying to treat them differently.
>> 
> http://www.python.org/doc/1.5.2/api/noneObject.html
> 
> 7.1.2 The None Object
> 
> PyObject * Py_None
>     The Python None object, denoting lack of value. This object has no
>     methods.


I would argue that this particular doc is badly worded. Because Python 
doesn't have uninitialized variables, programmers need a value to stand 
in for "I don't have a real value for this yet". By convention, None is 
usually that value, although object() is another reasonable choice, for 
when None is needed for something else.


>> > The value of a class is it's attributes? Are you saying that
>> > attributes of an object are part of its value?  That would mean that
>> > 'a' and b' below have different values?
>> > 
>> > class My_int(int):
>> >     def __init__(self): self.foo = None
>> 
>> That won't work you know.
> 
> Perhaps not, but it illustrates the point.  This *does* work:
> 
>>>> class myint(int):
> ...     def __init__(self, val):
> ...             int.__init__(val)
> ...             self.foo = None
> ...
>>>> b=myint(3)
>>>> b
> 3
>>>> b.foo
>>>> print b.foo
> None
>>>> a=3
>>>> a==b
> True
> 
> So, your description of value is not consistent with Python's
> behavior...  Python says the two objects I just created have the same
> value.  But by your definition, they don't.  One of you is wrong... ;-)

No, Python says that the two objects are equal. That's not the same thing.

Unicode strings and byte strings are not the same things:

>>> u'3' == '3'
True

Consider also:

>>> int(3) == float(3)
True
>>> decimal.Decimal(3) == int(3)
True
>>> decimal.Decimal(3) == float(3)
False


 
>> That depends on whether the existence of foo makes a difference to you
>> or not. Consider pickle. Since pickle can't predict what aspects of the
>> object are important, it must treat *everything* as significant, and
>> pickle will absolutely treat a and b as having different values.
> 
> I don't think that's clear...  pickle will treat a and b as having
> different *data*...  

Define data, and how is it different from value? 


> For what it's worth, I think the statement in the
> language reference that all objects have a type, an ID, and a value is
> quite a poor choice of words.  Back in 2000, Frederik Lundh put it much
> more accurately, I think:
> 
>   http://effbot.org/zone/python-objects.htm

Yes. For content, you can also say state.


 
>> I see you are still insisting that value is something that objects
>> "have" rather than "are".
> 
> This falls down, say, for a date object which has the value of the
> string representation of the date when printed, and a numeric value (or
> some other time object) when used in other expressions, both from a
> philisophical and practical standpoint.

No, the value of a date object is neither its printable string 
representation, nor the implementation-dependent numeric value in seconds.


> Furthermore it falls down semantically; an object has parts that are not
> part of its value, and therefore the value and the object can not be the
> same.  The value is merely one attribute (natural language, not Python
> definition) of the object.

I don't agree that this necessarily follows. We say that the value of an 
symbol is that which the symbol represents. Consider a map, with a little 
radioactive symbol representing a nuclear reactor. Note that the same 
symbol is used for the 100 megawatt CANDU reactor here, and the 2 
megawatt heavy-water research reactor over there: radically different 
things but denoted by the same symbol.

If protesters cut down the chainlink fence surrounding the power station, 
do we have to gather up all the maps and erase a pixel from the symbol? 
How do we identify which pixel represents the fence and which ones 
represents the reactor core?

I would answer these questions by saying that for the purposes of the 
map, the chainlink fence is unimportant. The size of the reactor is 
unimportant. We can use the same symbol for both reactors, despite the 
differences, because for the purpose of mapping the only thing that 
matters is the nuclear core. we say that, for the purpose of the map, the 
two sites have the same value. The fence is like an attribute of the 
reactor object, and irrelevant.

But if you're providing security cameras for the site, then the fence is 
very important. For that purpose, you can't interpret both reactors the 
same. You might have to use a different symbol, say "Reactor 1" and 
"Reactor 2", for them, and you would *not* say that Reactor 1 and Reactor 
2 have the same value.



-- 
Steven