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

Terry Reedy tjreedy at udel.edu
Sat Nov 15 18:12:34 EST 2008


rurpy at yahoo.com wrote:
> On Nov 14, 8:56 pm, Terry Reedy <tjre... at udel.edu> wrote:
> 
> First of all, thanks.  Thanks to your answers I have
> finally been able to formulate a concept of Python
> values.  Now we'll see if it is valid/usable... :-)

Good questions help refine a concept.

>>> * Can I create an object that has a value that
>>>  is the same as int(3) without somehow using an
>>>  int(3) object in its construction?
>> Yes: 1 + 2
> 
> OK, but my question was too strict.
> "1 + 2" is shorthand for: int(1).__add__(int(2))

Both are shorthand for int.__add__(int(1),int(2)).  Liskov intentionally 
designed CLU with methods belonging to classes, not instances, because 
the binary op case does not fit the idea of some that a method is a 
message to an actor, that 1+2 means 'hey 1, add 2 to yourself'.

...
>>> * Does an object's behavior (methods) affect
>>>  its value?
>> My first answer is No.  Instance methods are attributes of a class and,
>> in most cases, the value of a class.
> 
> The value of a class is it's attributes?
> Are you saying that attributes of an object are
> part of its value?

Either: objects have 4 aspects -- id, class, attributes, and value
Or: attributes are included with value, so that obs have 3 aspects -- 
id, class, and value.
[Or: (Aprano) id, class, and attributes are included with value.]

I an not sure yet which viewpoint/formulation is the more useful. I 
answered from the 3-aspect viewpoint.  It is more traditional, but 
probably predates 'objects with attributes' as opposed to 'strucures 
with fields'.  But I suspect that the values of the fields would be 
considered the value of the structure. In any case, I have also 
considered the 4-aspect view also.

> That would mean that 'a'
> and b' below have different values?
> 
> class My_int(int):
>     def __init__(self): self.foo = None
> a = int(3)
> b = My_int(3)

Yes, and indeed, a.foo raises an exception and b.foo does not.

If attributes are included with value, then value must be subdivided 
into attributes and private value.  For numbers, the private value is 
the numerical value; it cannot be accessed separate from the number 
object itself.  Strings have a private value which can be exposed a 
character or slice at a time.  Numbers and strings are the two classes 
with literals.

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

That is the first choice of the either/or choice above.  It is okay as 
long as it is understood that 'value' is being used in a restrictive sense.

Here is one reason I have not adopted it yet (and I need to make a 
choice for the algorithm book I am writing).  Consider a(b).  This means 
'call a with argument b'.  I would rather say 'the value of a is what it 
does with b (for all possible b), which is to say, the mapping it 
implements', than to explain calling in terms of an 
implementation-dependent, essentially private, attribute structure.

So I am thinking I may go with
class: determines universe of possible values of instances and (with 
superclasses) functions such instances can work with.  'Functions' 
includes all types of syntactic expressions.
value: determine specific result when used as argument in functions

Terry Jan Reedy




More information about the Python-list mailing list