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

[Derek Martin]

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).  Zero is a value,
whereas None is specifically intended to denote the lack of any value.
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).

> "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.

> 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. 

> > 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... ;-)

> 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*...  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

I think it's up for debate whether the value of attribute of an object 
is part of the object's value, if that attribute can never be the
evaluated value of the object itself in an expression -- though only
because it's a semantic argument, and the semantics haven't been
defined.  I don't think choosing to say that it is or isn't makes
any practical difference, at all.

> But other functions may have weaker constraints. Consider sum([a, b]). 
> The function sum makes no promises that it will return the same type as 
> it's arguments. Since, *for the purposes of addition*, the foo attribute 
> has no significance, sum() makes no promise whether the sum of a and b 
> will include the foo attribute. In fact it does not. As far as addition 
> is concerned, a and b have the same value, and the foo attribute is lost.

You seem to be making my point, that the value of an object is
context-specific...

> > I propose that attributes are not part of a class' (or any other
> > object's) value and that a class object has no value.

Both of these suggestions are clearly problematical, as when used in
an expression, an object can (and usually does) evaluate to some value
for the purpose of evaluating the expression, and that value may be an
attribute of the class, depending on what we decided is the right
answer to the question above.  

> 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.

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.

[...]
> In other words: the value of an expression is the object that the 
> expression evaluates to.

So too is the value of an object. :)

-- 
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20081116/44513b7a/attachment-0001.sig>