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

[Aaron Brady]

On Nov 15, 12:51 am, Steven D'Aprano <st... at REMOVE-THIS-
cybersource.com.au> wrote:
> On Fri, 14 Nov 2008 22:56:52 -0500, Terry Reedy wrote:
snip
> I would say that the answer to this is, "Would you like to include
> behaviour in value?". Let me give you an example:
>
> class String(string):
>     def upper(self):
>         return "spam"
>
> s1 = "Norwegian Blue"
> s2 = String("Norwegian Blue")
>
> Do s1 and s2 have the same value?
>
> Using definition (1) above, we can see that the names s1 and s2 refer to
> different objects, so the names have different values.
>
> Using definition (2), the objects s1 and s2 have different concrete
> expressions, and so they are different values. (Remember: the object is
> the value.) But from definition (3) they both represent that same
> abstract string, so if I care only about that level of description, I'd
> say yes they *have* the same value but *are* different values.
>
> Assuming I cared about the behaviour of upper(), then s2 is probably not
> suitable for my purposes and so I would like to distinguish s1 from s2.
> I'd insist that they have different values which merely looked the same
> under equality. To use the bank note analogy, then s1 is legal tender but
> s2 is just a very good forgery.
>
> But note that to a collector of forgeries, s2 might be more valuable than
> s1, and presumably the writer of class String had a reason for the
> behaviour given. The answer to the question "do s1 and s2 have different
> values" will depend on why you are asking.
>
snip
> I would say that although value is dependent on context, that's no excuse
> for concluding that it has no meaning. If you look too closely at
> *anything*, it becomes fuzzy. (Well, with the possible exception of pure
> mathematics.)
>
> --
> Steven

I'm reading that the result of the __eq__ comparison isn't the only
meaning of value, and that there is more than one.

>>> class String(str):
...     def upper(self):
...         return "spam"
...
>>> s1 = "Norwegian Blue"
>>> s2 = String("Norwegian Blue")
>>> s1== s2
True
>>> s1.upper()== s2.upper()
False

Murmur, good.  I could see rejecting that two objects of different
types can have the same value.  I could also see rejecting that 'the
value than an object is' is nonsense, permitting only 'the value that
an object has'.  However, as a counterexample, 'x has the value [1, 2,
3]' and 'x is [1, 2, 3]' are both colloquially sensical statements,
though the latter is imprecise, because 'x is [1, 2, 3], y is [1, 2,
3], x is not y'; certainly '[1, 2, 3]' is neither 'x' nor 'y', and
identity is a commutative relation.

If you'll permit a tangent into another (computer) language, I don't
have a problem saying either that the value of x in 'int* x' in C is a
memory address, or that its value is an integer, which stance is
definitely prone to miscommunication.  I still maintain that passing
an object by value calls its copy constructor.