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
pgpKjN49iig96.pgp
Description: PGP signature
-- http://mail.python.org/mailman/listinfo/python-list