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

[Antoon Pardon]

On 2008-11-20, greg <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>
>> You are changing your argument. In a follow up you
>> made the point that call by value should be as it
>> was intended by the writers of the algol 60 report.
>
> No, I was countering the argument that "call by value"
> is short for "call by copying the value". I was pointing
> out that the inventors of the term didn't use any such
> words.

That doesn't counter that that was intended.

> Arguing that their words were intended to imply copying,
> as part of the essence of the idea, is making an even
> bigger assumption about their intentions, IMO.

In their document assignment was a copying.

IMO the bigger assumption is to assume that these people
wanted to define "call by value" for languages which
would have different assignment semantics than their
own.

> Rather it seems to me that the essence of the idea they
> had in mind is that call-by-value is equivalent to
> assignment.

In their particular context.

> Furthermore, I don't seem to be alone in coming to that
> conclusion -- the designers of other dynamic languages
> appear to be using the same logic when they describe
> their parameter passing as call-by-value.

So what. Some designers do and some don't and some
make a particular effort to do different.

-- 
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list

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

[Steven D'Aprano]

On Sun, 23 Nov 2008 09:24:05 -0600, Derek Martin wrote:

> On Tue, Nov 18, 2008 at 09:23:30AM +, Steven D'Aprano wrote:
>> > How I can answer the question, "are the objects a and b the same or
>> > different"? I can look at every aspect of each object, looking for
>> > something that is different.
>> 
>> Well, sure, if you care *that much* about potentially trivial aspects.
>> I have a ten dollar note with a spec of dirt on one corner, and a ten
>> dollar note with a slightly larger spec of dirt on a different corner.
>> I'd agree with you that they are not "the same" in every aspect, but
>> they're the same in every way I care about.
> 
> It's trivial to show that this is not necessarily the case -- you just
> haven't thought of all the ways in which a difference might matter to
> you..
> 
> Suppose that one of the 10-dollar bills had a serial number which was
> never printed by the government (i.e. it is counterfiet).  Are they
> still the same in every way that you care about?

Derek, I realise that this is the Thread From Hell That Just Won't Die, 
but you really should make an effort to read all of it before jumping 
into the middle of it. You're not saying anything that I haven't already 
said. I'm happy to have reasoned support from others, but you're arguing 
with the wrong guy: I've been saying that "the same value" of two objects 
is context-dependent since earlier in this thread than you have.

And let me repeat Steve Holden's comment about unnecessarily quoting text 
you aren't responding to. (Approximately) 260 lines of dead text at the 
end of your post is excessive and rude. Please trim it in the future.

[...]


-- 
Steven
--
http://mail.python.org/mailman/listinfo/python-list

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

[Steve Holden]

Derek Martin wrote:
[some stuff, followed by about 32k of unnecessarily quoted crap]

It would be helpful if you'd take the time to trim your replies
appropriately.

regards
 Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/

--
http://mail.python.org/mailman/listinfo/python-list

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

[Derek Martin]

On Tue, Nov 18, 2008 at 09:23:30AM +, Steven D'Aprano wrote:
> > How I can answer the question, "are the objects a and b the same or
> > different"? I can look at every aspect of each object, looking for
> > something that is different.
> 
> Well, sure, if you care *that much* about potentially trivial aspects. I 
> have a ten dollar note with a spec of dirt on one corner, and a ten 
> dollar note with a slightly larger spec of dirt on a different corner. 
> I'd agree with you that they are not "the same" in every aspect, but 
> they're the same in every way I care about.

It's trivial to show that this is not necessarily the case -- you just
haven't thought of all the ways in which a difference might matter to
you..

Suppose that one of the 10-dollar bills had a serial number which was
never printed by the government (i.e. it is counterfiet).  Are they
still the same in every way that you care about?

What is the value of these two objects?  Is it the same?

The answer, in both cases, is, "it depends."  The value of both is
context-specific, just as I argue is the value of a python object.
First let's briefly examine the value of the counterfiet:

The "intrinsic" value (or rather, the value generally accepted by the
authorities) of the counterfeit is zero.  However, if you have one in
your hand, and you pass it to a merchant who is not able to detect
that it is a counterfeit, then, isn't its value $10 in that context?
If you walk away from the merchant with $10 worth of goods (and/or
change in non-counterfeit currency), then I would say it would have to
be, *in that context*.  

Now suppose that the merchant is actually a U.S. Secret Service agent
investigating counterfeit money.  He notices the bill and arrests you.
What is the value of the bill now?  I doubt you could really measure
it, except perhaps in terms of the amount of money it would cost you
to defend yourself in court (if your case went to court), the amount
of hastle to deal with the authorities, etc.  Suffice it to say that
the value is rather negative, possibly with a very high magnitude,
depending on what happens next.

What about the genuine $10 bill?  

If you take it to your local mall, or your local gas station, or your
corner grocer, it's clearly worth $10... or is it?  Prices of gasoline
vary from station to station, city to city, state to state, even if
the gas is sold by the same company.  A can of peas might be $0.89 at
a market in New Hampshire, or the same can of peas might be $1.59 at a
market in down town Manhattan.  And if you take your $10 bill to pay
for your favorite cup of coffee at Starbucks in your city, it might
cost you $4 with change back of $6...  But if you bring that same $10
bill to a Starbucks in a small city in Germany, good luck getting any
coffee...

Just as in the real world, the value of a Python object depends on the
context in which it is evaluated.

> > What are the aspects of the object that I can look at?
> > 
> > id(obj) will give me the identity but I know that will be different and
> > so its irrelevant.
> 
> Philosophically, no, not irrelevant. You haven't explicitly defined "the 
> same" in enough detail to make that call. Perhaps because the objects are 
> in different locations (different IDs) is enough to make them different, 
> even if everything else about them is identical.
> 
> For example, consider the two electrons around a helium nucleus. They 
> have the same mass, the same speed, the same spin, the same electric 
> charge, the same magnetic moment, they even have the same location in 
> space (technically, the same wave function). They are identical in every 
> possible way. Are they the same electron, or two different electrons? 
> What does the question even mean?
> 
> My point is that as a philosophical position, identity may or may not 
> count as "sameness". It depends on the circumstances.
> 
> 
> 
> > What else can we look at?  We can go through each
> > attribute of the objects looking for an attribute that one has and the
> > other doesn't, or for attributes of the same name that are different.
> > 
> > We look at .__class__, .__delattr__,  and so on and they are all the
> > same until we come to .foo and note that a.foo and b.foo are different.
> > One is an int(1) object, the other is an int(2) object.  So we can say
> > that a and b are different.
> 
> Philosophically, sure, but practically, perhaps not. The foo attribute 
> may be entirely irrelevant to your purposes, the equivalent of a random 
> speck of dirt or a slight tear on a ten dollar note.
> 
> Luckily, Python doesn't try to guess whether differences are significant 
> or not. You can override the __eq__ method on classes and choose for 
> yourself what properties of a class are differences that make a 
> difference and which are mere markers of no particular concern.
> 
>  
> > Lets do the same with these two objects:
> > 
> >   a = int(2)
> >   b = int(3)
> > 
> > When we do that, we find no difference!

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

[Arnaud Delobelle]

Aaron Brady <[EMAIL PROTECTED]> writes:

> Truth and clarity are not tired of this thread.

This is such a marvellously economic way of putting it, it's poetic!

-- 
Arnaud
--
http://mail.python.org/mailman/listinfo/python-list

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

[Aaron Brady]

On Nov 22, 8:40 am, Joe Strout <[EMAIL PROTECTED]> wrote:
> On Nov 22, 2008, at 4:08 AM, Aaron Brady wrote:
>
> > Furthermore, to apply c-b-v to Python, you have to
> > introduce the concept of pointers, which is ostensibly non-native for
> > human programmers.
>
> Not necessarily "pointers" per se -- any type of object references  
> will do, and yes, Python has those in spades.

Humans don't.  That's my point.

> >  You'd have a pretty hard time making the case that c-b-v is 'round  
> > peg, round hole' for Python.
>
> I didn't find it all that hard:  >  Just describe it and give it a name.
>
> OK: "Python variables contain object references, which are copied from  
> the actual parameter expression to the formal parameter.  This  
> evaluation strategy is named 'call-by-value,' though some authors use  
> the term 'call-by-sharing' to indicate the specific case of call-by-
> value where the values passed are object references."

Better: Objects are passed to functions without copying, and
assignment assigns a new identity to the variable, without changing
the old object.  Round peg, round hole.

The only purpose it serves to keep bringing up reference this and
reference that, is so you can 'square peg, round hole' the term 'call-
by-value'.

> (I should add that last bit to my web page -- I'll try to do that this  
> weekend.)

What you should do, is add mine to the 'short answer' section, and
yours to the 'long answer' section.  Diversify your portfolio.

> P.S. I've pretty well tired of this thread, but I can't let Greg stand  
> up for truth and clarity all by himself...

Truth and clarity are not tired of this thread.
--
http://mail.python.org/mailman/listinfo/python-list

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

[Joe Strout]

On Nov 22, 2008, at 4:08 AM, Aaron Brady wrote:


Furthermore, to apply c-b-v to Python, you have to
introduce the concept of pointers, which is ostensibly non-native for
human programmers.


Not necessarily "pointers" per se -- any type of object references  
will do, and yes, Python has those in spades.


 You'd have a pretty hard time making the case that c-b-v is 'round  
peg, round hole' for Python.


I didn't find it all that hard: 



 Just describe it and give it a name.


OK: "Python variables contain object references, which are copied from  
the actual parameter expression to the formal parameter.  This  
evaluation strategy is named 'call-by-value,' though some authors use  
the term 'call-by-sharing' to indicate the specific case of call-by- 
value where the values passed are object references."


(I should add that last bit to my web page -- I'll try to do that this  
weekend.)


Cheers,
- Joe

P.S. I've pretty well tired of this thread, but I can't let Greg stand  
up for truth and clarity all by himself...


--
http://mail.python.org/mailman/listinfo/python-list

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

[Aaron Brady]

On Nov 21, 8:53 pm, greg <[EMAIL PROTECTED]> wrote:
> Aaron Brady wrote:
> > Call-by-value has other characteristics that Python does not
> > meet.
>
> The designers of most other dynamic languages don't
> seem to share that opinion, since they use the term
> call-by-value just as though it *does* mean call-
> by-assignment and nothing more.

The experts are divided.  There is no science that tells you how to
extrapolate a term, such as say, the Japanese equivalent of meat &
potatoes or apple pie, or c-b-v into a language that doesn't have a
copy constructor.  Furthermore, to apply c-b-v to Python, you have to
introduce the concept of pointers, which is ostensibly non-native for
human programmers.  You'd have a pretty hard time making the case that
c-b-v is 'round peg, round hole' for Python.  Just describe it and
give it a name.
--
http://mail.python.org/mailman/listinfo/python-list

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

[greg]

Aaron Brady wrote:


Call-by-value has other characteristics that Python does not
meet.


The designers of most other dynamic languages don't
seem to share that opinion, since they use the term
call-by-value just as though it *does* mean call-
by-assignment and nothing more.

--
Greg
--
http://mail.python.org/mailman/listinfo/python-list

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

[Aaron Brady]

On Nov 21, 7:06 pm, greg <[EMAIL PROTECTED]> wrote:
> Aaron Brady wrote:
> > Tell me, what happens during a call to the following C++ function?
>
> > void f( std::vector< int > x );
>
> The same thing as would happen if you wrote
>
>    std::vector x = actual_parameter_expression;
>
> > what happens during a call to the following Python
> > function?
>
> > def f( x ): ...
>
> The same thing as would happen if you wrote
>
>    x = actual_parameter_expression
>
> > If not, which one is call-by-value?
>
> They're both call-by-value, because they're both equivalent to
> assignment according to the rules of the language concerned.

No, you have described call-by-equals-sign, or call-by-assignment.
While call-by-assignment and call-by-value are equivalent in C++, that
does not make your rule hold for all languages.  Python is call-by-
assignment too, as well as call-by-sharing.  Just because a language
is call-by-assignment, is not sufficient (or necessary) to be call-by-
value.  Call-by-value has other characteristics that Python does not
meet.

--
http://mail.python.org/mailman/listinfo/python-list

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

[greg]

Steven D'Aprano wrote:


You've just *assumed* that assignment in Algol 60 doesn't involving
copying.


I've done no such thing. I've *refrained* from assuming that
the "assignment" in the definition always has to refer to
Algol 60 assignment. You're the one insisting on tying
everything to Algol.

I don't know whether the Algol committee had such a general
meaning in mind when they wrote that document. It's quite
likely they weren't thinking that far ahead. But the fact is
that it *can* be generalized to other languages in an
obvious and useful way, and many language designers after
them have generalized it in exactly that way.


(I wait now with bated breath for somebody to point out some Python
implementation or feature where assignment doesn't make a copy...)


Ah crap, I meant *Pascal*.


Not in plain Pascal, but Apple's Object Pascal (and probably
other OO Pascal dialects) have object types that are implicitly
referred to by pointers, like Python objects -- and when you
pass one by value, only the pointer is copied, not the whole
object.

--
Greg
--
http://mail.python.org/mailman/listinfo/python-list

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

[greg]

Aaron Brady wrote:


Tell me, what happens during a call to the following C++ function?

void f( std::vector< int > x );


The same thing as would happen if you wrote

  std::vector x = actual_parameter_expression;


what happens during a call to the following Python
function?

def f( x ): ...


The same thing as would happen if you wrote

  x = actual_parameter_expression


If not, which one is call-by-value?


They're both call-by-value, because they're both equivalent to
assignment according to the rules of the language concerned.

Whether they're "the same" depends on what you mean by "same".
If you define "same" in such a way that they're not, then that
definition of "same" is irrelevant to the matter at hand.

--
Greg
--
http://mail.python.org/mailman/listinfo/python-list

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

[greg]

Aaron Brady wrote:


But wait, is that true assignment?


It's assignment, but it's not really copying an object. No new
objects are being created -- rather, some of the items within
the lhs object are being rebound to already-existing objects.

It would be possible for the lhs object's __setitem__ method
to be defined so that it created new objects, but then it
would be the __setitem__ method doing that, not the assignment
statement itself.

None of this is really relevant anyway, since the assignment
that call-by-value implies is always to a bare local name, and
there is no way that kind of assignment can ever create a new
object.

--
Greg
--
http://mail.python.org/mailman/listinfo/python-list

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

[Aaron Brady]

On Nov 21, 4:33 am, Duncan Booth <[EMAIL PROTECTED]> wrote:
> Aaron Brady <[EMAIL PROTECTED]> wrote:
> >> a[:] = [1, 2, 3]
>
> > No, that's not assignment, it's syntactic sugar for a __setslice__
> > call.  No copies here.
>
> Oh dear, perhaps you had better get the Python developers to update the
> grammar that Python uses as that seems to think it's an assignment:

Well, the docs don't take my side either.

"object.__setitem__(self, key, value)
Called to implement assignment to self[key]."

But wait, is that true assignment?

"Assignment statements
Assignment statements are used to (re)bind names to values and to
modify attributes or items of mutable objects:"

"If the target is an identifier (name):
... the name is bound to the object in the current global namespace."

The latter is the case of interest.



--
http://mail.python.org/mailman/listinfo/python-list

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

[Duncan Booth]

Aaron Brady <[EMAIL PROTECTED]> wrote:
>> a[:] = [1, 2, 3]
> 
> No, that's not assignment, it's syntactic sugar for a __setslice__
> call.  No copies here.
> 

Oh dear, perhaps you had better get the Python developers to update the 
grammar that Python uses as that seems to think it's an assignment:

assignment_stmt ::= (target_list "=")+ (expression_list | 
yield_expression) 
target_list ::= target ("," target)* [","] 
target ::= identifier 
  | "(" target_list ")" 
  | "[" target_list "]" 
  | attributeref 
  | subscription 
  | slicing 


:^)

-- 
Duncan Booth http://kupuguy.blogspot.com
--
http://mail.python.org/mailman/listinfo/python-list

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

[Aaron Brady]

On Nov 21, 3:11 am, Duncan Booth <[EMAIL PROTECTED]> wrote:
> Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> > On Fri, 21 Nov 2008 03:32:25 +, Steven D'Aprano wrote:
>
> >>> Rather it seems to me that the essence of the idea they had in mind
> >>> is that call-by-value is equivalent to assignment.
>
> >> You've just *assumed* that assignment in Algol 60 doesn't involving
> >> copying. Based on the very little I know about Algol, I think that is
> >> a very unsafe assumption. I know significantly more about Pascal, and
> >> in Pascal, assignment *is* copying.
>
> >> (I wait now with bated breath for somebody to point out some Python
> >> implementation or feature where assignment doesn't make a copy...)
>
> > Ah crap, I meant *Pascal*. Python of course doesn't copy objects when
> > you assign them.
>
> I think you meant "Python of course doesn't copy objects when you rebind
> names". Python can (and sometimes does) make copies of objects when you
> assign them, , but only if the assignment involves something other than
> simply rebinding a name. e.g.
>
> a[:] = [1, 2, 3]

No, that's not assignment, it's syntactic sugar for a __setslice__
call.  No copies here.
--
http://mail.python.org/mailman/listinfo/python-list

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

[Duncan Booth]

Steven D'Aprano <[EMAIL PROTECTED]> wrote:

> On Fri, 21 Nov 2008 03:32:25 +, Steven D'Aprano wrote:
> 
>>> Rather it seems to me that the essence of the idea they had in mind
>>> is that call-by-value is equivalent to assignment.
>> 
>> You've just *assumed* that assignment in Algol 60 doesn't involving
>> copying. Based on the very little I know about Algol, I think that is
>> a very unsafe assumption. I know significantly more about Pascal, and
>> in Pascal, assignment *is* copying.
>> 
>> (I wait now with bated breath for somebody to point out some Python
>> implementation or feature where assignment doesn't make a copy...)
> 
> Ah crap, I meant *Pascal*. Python of course doesn't copy objects when
> you assign them.
> 
> 
I think you meant "Python of course doesn't copy objects when you rebind 
names". Python can (and sometimes does) make copies of objects when you 
assign them, , but only if the assignment involves something other than 
simply rebinding a name. e.g.

a[:] = [1, 2, 3]



-- 
Duncan Booth http://kupuguy.blogspot.com
--
http://mail.python.org/mailman/listinfo/python-list

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

[Steven D'Aprano]

On Fri, 21 Nov 2008 03:32:25 +, Steven D'Aprano wrote:

>> Rather it seems to me that the essence of the idea they had in mind is
>> that call-by-value is equivalent to assignment.
> 
> You've just *assumed* that assignment in Algol 60 doesn't involving
> copying. Based on the very little I know about Algol, I think that is a
> very unsafe assumption. I know significantly more about Pascal, and in
> Pascal, assignment *is* copying.
> 
> (I wait now with bated breath for somebody to point out some Python
> implementation or feature where assignment doesn't make a copy...)

Ah crap, I meant *Pascal*. Python of course doesn't copy objects when you 
assign them.


-- 
Steven


--
http://mail.python.org/mailman/listinfo/python-list

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

[John Nagle]

Steven D'Aprano wrote:

On Thu, 20 Nov 2008 14:22:50 +1300, greg wrote:


Antoon Pardon wrote:


You are changing your argument. In a follow up you made the point that
call by value should be as it was intended by the writers of the algol
60 report.

No, I was countering the argument that "call by value" is short for
"call by copying the value". I was pointing out that the inventors of
the term didn't use any such words.


Nor did they define what assignment means, and their definition of 
"value" seems to exclude such things as strings.





Arguing that their words were intended to imply copying, as part of the
essence of the idea, is making an even bigger assumption about their
intentions, IMO.

Rather it seems to me that the essence of the idea they had in mind is
that call-by-value is equivalent to assignment.


You've just *assumed* that assignment in Algol 60 doesn't involving 
copying. Based on the very little I know about Algol, I think that is a 
very unsafe assumption. I know significantly more about Pascal, and in 
Pascal, assignment *is* copying.


(I wait now with bated breath for somebody to point out some Python 
implementation or feature where assignment doesn't make a copy...)


   In stock ALGOL-60, there are only the primitive types, and assignment
of them is a copy.  Most useful implementations had strings, and Simula,
which was an ALGOL extension, had objects.

   Simula had value parameters, reference parameter, and name parameters.
For assignment, ":=" specified a value assignment, and ":-" specified
a reference assignment.

John Nagle
--
http://mail.python.org/mailman/listinfo/python-list

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

[Steven D'Aprano]

On Wed, 19 Nov 2008 11:20:05 -0500, Terry Reedy wrote:

>> It is useful and convenient to have "null values" like None, but it
>> isn't useful to say that None is not a value.
> 
> I never said that.  

But you've been defending the views of somebody who did. If you're going 
to play Devil's Advocate for views you don't believe (and I've been known 
to do the same myself), make it clear that this is what you're doing -- 
or at least don't take criticisms of those views as attacks against you.


> I said that it has no attributes (other than
> __class__) and no private data.  In other words, no content, no state.
> It is an empty object, just like objects()s, and similar in that to
> empty collections.

Yes, but the lack of state is itself a state, just like 0 is still an int 
despite being the lack of quantity. That's the point I'm trying to make: 
having no state is itself a state, just like the empty set is a set. 
Because of its particular state ("empty state") None has behaviour 
different from most other objects, in the same way that 0 behaves 
differently from other ints (e.g. a*x==x for all values of a only if 
x==0). But singling None out as "not a value" is just like singling 0 as 
as not an int.


-- 
Steven
--
http://mail.python.org/mailman/listinfo/python-list

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

[Steven D'Aprano]

On Thu, 20 Nov 2008 14:22:50 +1300, greg wrote:

> Antoon Pardon wrote:
> 
>> You are changing your argument. In a follow up you made the point that
>> call by value should be as it was intended by the writers of the algol
>> 60 report.
> 
> No, I was countering the argument that "call by value" is short for
> "call by copying the value". I was pointing out that the inventors of
> the term didn't use any such words.

Nor did they define what assignment means, and their definition of 
"value" seems to exclude such things as strings.



> Arguing that their words were intended to imply copying, as part of the
> essence of the idea, is making an even bigger assumption about their
> intentions, IMO.
> 
> Rather it seems to me that the essence of the idea they had in mind is
> that call-by-value is equivalent to assignment.

You've just *assumed* that assignment in Algol 60 doesn't involving 
copying. Based on the very little I know about Algol, I think that is a 
very unsafe assumption. I know significantly more about Pascal, and in 
Pascal, assignment *is* copying.

(I wait now with bated breath for somebody to point out some Python 
implementation or feature where assignment doesn't make a copy...)



-- 
Steven
--
http://mail.python.org/mailman/listinfo/python-list

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

[Aaron Brady]

On Nov 19, 7:22 pm, greg <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
> > You are changing your argument. In a follow up you
> > made the point that call by value should be as it
> > was intended by the writers of the algol 60 report.
>
> No, I was countering the argument that "call by value"
> is short for "call by copying the value". I was pointing
> out that the inventors of the term didn't use any such
> words.
>
> Arguing that their words were intended to imply copying,
> as part of the essence of the idea, is making an even
> bigger assumption about their intentions, IMO.
>
> Rather it seems to me that the essence of the idea they
> had in mind is that call-by-value is equivalent to
> assignment.
>
> Furthermore, I don't seem to be alone in coming to that
> conclusion -- the designers of other dynamic languages
> appear to be using the same logic when they describe
> their parameter passing as call-by-value.
>
> Here's an example from "The SNOBOL Programming Language",
> 2nd Edition, by R. E. Griswold, J. F. Poage and I. P.
> Polonsky. On p. 15:
>
>    Arguments are passed by value and may be arbitrarily
>    complex expressions.
>
> and later on p. 95:
>
>    When a call to a programmer-defined function is made, the
>    arguments to the call are evaluated first. Before execution
>    of the procedure begins ... new values are assigned to these
>    variables as follows: ... (2) the formal arguments are
>    assigned their values.

Tell me, what happens during a call to the following C++ function?

void f( std::vector< int > x );

Is it the same as what happens during a call to the following Python
function?

def f( x ): ...

If not, which one is call-by-value?
--
http://mail.python.org/mailman/listinfo/python-list

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

[greg]

Antoon Pardon wrote:


You are changing your argument. In a follow up you
made the point that call by value should be as it
was intended by the writers of the algol 60 report.


No, I was countering the argument that "call by value"
is short for "call by copying the value". I was pointing
out that the inventors of the term didn't use any such
words.

Arguing that their words were intended to imply copying,
as part of the essence of the idea, is making an even
bigger assumption about their intentions, IMO.

Rather it seems to me that the essence of the idea they
had in mind is that call-by-value is equivalent to
assignment.

Furthermore, I don't seem to be alone in coming to that
conclusion -- the designers of other dynamic languages
appear to be using the same logic when they describe
their parameter passing as call-by-value.

Here's an example from "The SNOBOL Programming Language",
2nd Edition, by R. E. Griswold, J. F. Poage and I. P.
Polonsky. On p. 15:

  Arguments are passed by value and may be arbitrarily
  complex expressions.

and later on p. 95:

  When a call to a programmer-defined function is made, the
  arguments to the call are evaluated first. Before execution
  of the procedure begins ... new values are assigned to these
  variables as follows: ... (2) the formal arguments are
  assigned their values.

--
Greg
--
http://mail.python.org/mailman/listinfo/python-list

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

[Steve Holden]

[EMAIL PROTECTED] wrote:
> On Nov 18, 10:22 am, Steve Holden <[EMAIL PROTECTED]> wrote
> in thread "Python-URL! weekly Python news and links (Nov 17)":
>> [EMAIL PROTECTED] wrote:
>> [...]
>>> One of the reasons I would like to formulate a good
>>> model of an object's value and type is so that I could
>>> try to offer something better.  Responses like yours
>>> are significantly demotivating.
>> And yet you argue when people try to explain to you that objects don't
>> *have* values, objects *are* values. Objects have attributes, which are
>> references to other values. One of an object's attributes is its type.
> 
> I am sorry for arguing with you.  I hear you
> and others saying that the value (in the english
> language sense of value) of an object *is* the
> object.
> 
That's OK. I don't assume you are arguing to be difficult, but to cast
light on a dark area.

> But before I address that, I am a little confused
> by what you wrote above.  Quoting the PLR again,
> "Every object has an identity, a type and a value."
> I presumed "value" to include attributes.  Are you
> saying the correct statement in the PLR should have
> been, "Every object has an identity, attributes, and
> a value"?
> 
> The text below refers to identity, type and value
> per the PLR, but you can substitute "attributes"
> for type without affecting the logic.
> 
> Here is why I am having trouble accepting the
> explanations you and others have kindly offered
> me.  If values are objects then the words "object"
> and "value" are synonymous, yes?  Fine, I can see
> that could be a desirable thing.  Value is more
> natural than object for people coming to Python,
> for example.
> 
> But if you use the word value synonymously with
> object, then the PLR statement that "an object
> has identity, type, and value" is the same as "an
> object has identity, type, and itself".  We know
> the object is itself!　That's tautological.  So
> what is the point of using the term value in the
> definition of "object"?  You can just say "an object
> has identity and type, and we will also use the word
> value as a synonmym for object."
> 
> Other than cosmetics, the word "value" serves no
> purpose and we can replace it with "object" wherever
> we use it.  E.g. "the result of evaluating an
> expression is a value.", "the result of evaluating
> an expression is an object".  If value is the same
> as object, then Python objects have only identity
> and type.
> 
> But you know that's not true.  The types of int(2)
> and int(3) are the same.  Is the difference in
> behavior of the two objects due to their different
> identities?!  Python knows the object at 0x260FF44
> is a "2" object, and the object at 0x260FD60 is a
> "3" solely by virtue of their addresses?
> 
> Of course not.
> I hope you see why I find the "value is object"
> to be an unacceptable explanation of Python
> objects.
> 
I now understand where your confusion arises, and I also have to accept
that integer types have a value that isn't formally available as an
attribute.

However, I don't personally see the need to go beyond the Python object
"2", since operations involving that value are not programmed in Python
but in the underlying implementation language.

>> You seem to be hunting for the ineffable
>> "primitive value" that has no other attributes.
>> Such a thing doesn't exist.
> 
> Sorry to argue again, but I explained (in a
> previous post) why I believe such a thing does
> exist.  Specifically, it is necessary to explain
> the difference between the objects int(2) and
> int(3).  Perhaps if you tell me exactly what
> fault you find with that previous explanation
> (in light of my problem with "values are objects"
> above), I could reevaluate my understanding.

I suppose I was thinking more of the compound values than the primitive
immutable type instances. I take your point that int(3) and int(2) do
indeed differ by virtue of having different values for some "hidden
attribute" that isn't available to the Python programmer.

Since the differences aren't directly addressable in Python, however, I
prefer to ignore them :)

regards
 Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/

--
http://mail.python.org/mailman/listinfo/python-list

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

[Terry Reedy]

Steven D'Aprano wrote:

On Tue, 18 Nov 2008 15:55:10 -0500, Terry Reedy wrote:



To me, that distortion of his (and my) point is silly.  0 partipipates
in numerous integer operations, whereas None participates in no NoneType
operations.  (Neither has attributes.)  And that is the difference he is
pointing at.


Why do you care about built-in NoneType operations?


Because class-specific operations are what make one class, and instances 
thereof, different from another.  If you don't care about that, fine, 
but stop ridiculing those who do.  Why do you oppose people 
investigating specific differences?


> Why don't we count the infinite number of useful operations
> we can do to None that merely happen to not be built-in to the type?

Everything one can do with None is due to its status as a Python object.


We can convert None to a bool: bool(None)
We can append it to a list: alist.append(None)
We can convert it to a string: str(None), repr(None)
(In Python 2.6) We can ask how many bytes the None object uses.
We can ask the garbage collector how many objects refer to it: 
gc.get_referrers
We can count how many words have been written debating whether or not 
None is a value.


and so forth. These operations aren't methods on NoneType but that is not 
of any importance. The richness or poverty of methods in a class is 
irrelevant.


To you, but not to me.

It is useful and convenient to have "null values" like None, but it isn't 
useful to say that None is not a value.


I never said that.  I said that it has no attributes (other than 
__class__) and no private data.  In other words, no content, no state. 
It is an empty object, just like objects()s, and similar in that to 
empty collections.


Terry Jan Reedy

--
http://mail.python.org/mailman/listinfo/python-list

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

[Antoon Pardon]

On 2008-11-19, greg <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>> Call by value is officially defined in terms of assignment in
>> a context where assignments means copying and in a definition
>> of a specifix language.
>> 
>> You can't lift this part out of the definition of algol 60
>> and say it applies equally well in languages with different
>> assignment semantics.
>
> But many other language designers, of both static and
> dynamic languages, have done just that.
> I'm not saying it *has* to be interpreted that way,
> just that it *is* very often interpreted that way.
> So you can't claim that it's not common usage.

You are changing your argument. In a follow up you
made the point that call by value should be as it
was intended by the writers of the algol 60 report.

Now your falling back to how it is often interpreted.
It is very well possible that it is often interpreted
contrary to how it was intended. And since this
interpretation just as often results in misunderstandings
I don't think it is a usefull interpretation.

-- 
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list

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

[Gabriel Genellina]

En Wed, 19 Nov 2008 01:14:28 -0200, <[EMAIL PROTECTED]> escribió:

On Nov 18, 10:22 am, Steve Holden <[EMAIL PROTECTED]> wrote
in thread "Python-URL! weekly Python news and links (Nov 17)":

[EMAIL PROTECTED] wrote:
[...]

One of the reasons I would like to formulate a good
model of an object's value and type is so that I could
try to offer something better.  Responses like yours
are significantly demotivating.


And yet you argue when people try to explain to you that objects don't
*have* values, objects *are* values. Objects have attributes, which are
references to other values. One of an object's attributes is its type.


I am sorry for arguing with you.  I hear you
and others saying that the value (in the english
language sense of value) of an object *is* the
object.

But before I address that, I am a little confused
by what you wrote above.  Quoting the PLR again,
"Every object has an identity, a type and a value."
I presumed "value" to include attributes.  Are you
saying the correct statement in the PLR should have
been, "Every object has an identity, attributes, and
a value"?


I'll try to avoid any confusion here. I cannot say what defines a Python  
object in a generic way, but I do know what defines a CPython object. That  
is, I can talk about the current C implementation.
In CPython, an object is a C struct: PyObject. No more, no less. Most  
functions in the CPython API receive, return, or handle PyObject pointers  
everywhere. Every object in CPython is represented as a PyObject instance,  
and has the following properties:


 - An object has *identity*: its memory address, immovable, fixed once the  
object is allocated.
 - An object has a *type*: its ob_type field (a pointer to the type  
object). The type is uniquely defined - no type inference is ever done. It  
may be changed after the object was created but only if several  
prerequisites are met.

 - An object has *state* [or value]: everything else stored in the struct.

The PyObject struct is very small and contains nothing apart from the  
ob_type field [1]. So a PyObject instance has no state, there is nothing  
more defining it. A PyObject instance just "is": it has only identity and  
type, it does not carry any state.


More useful objects are built by extending the PyObject struct at the end  
- that is, adding more and more fields. By example, a PyIntObject adds a C  
"long" field. That new field is the only difference between a PyIntObject  
and a bare PyObject. We can say that a PyIntObject gained some "state":  
the integer stored inside that field; some people would like to say "its  
value". So, to describe completely a PyIntObject, one has to tell -in  
addition to its type and identity- *which* number it contains.


More complex objects are built using the same principle: by example, a  
PyFunctionObject contains nine more fields (func_code, func_doc, etc.) in  
addition to the bare PyObject. Those additional fields represent the  
"state" of the function object, and are required to describe it completely.


Instances of user-defined classes may contain arbitrary attributes; this  
is implemented using a dictionary. We refer to this dictionary as the  
'__dict__' attribute in Python code, but it is just another field in the  
object struct, as anything else. In other words, arbitrary attributes are  
also stored (indirectly) in the object struct.


So, at least when one looks at the CPython implementation, things are  
rather simple: an object is a struct located at certain address  
(determines its identity), has a certain type (a field in the struct) and  
has a state (everything else in the struct).


You may want to say "value" instead of "state" in all the above  
description, but I think it becomes confusing later.


Expressions: Evaluating an expression yields a result, and that result is  
an *object*. One could say "the value of this expression" -- but remember  
that it is an *object*, like everything else in Python. If one says  
"objects have identity, type and value", one cannot say at the same time  
"expressions return a value" because the word "value" has a different  
meaning in both sentences.


Calling: Same problem applies to "call-by-value". If one says that objects  
*have* a value (that implies that value is *part* of the object), it  
itsn't its "value" what is passed when a function call is made. The  
*whole* object is passed, not its "value" alone. Saying "call-by-object"  
describes more accurately what actually happens.


Conclusion: To avoid any ambiguity, I'd say that "objects have identity,  
type, and state" (not value), "expressions evaluate to an object" (again,  
not value), and "Python passes arguments to functions using a  
call-by-object protocol". Given these terms, even "the value of this  
expression" might be acceptable because "value" could not be confused with  
any "part" of an object.



Here is why I am having trouble accepting the
explanations you and others have kindly 

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

[Steven D'Aprano]

On Tue, 18 Nov 2008 15:55:10 -0500, Terry Reedy wrote:

> Steven D'Aprano wrote:
>> On Sun, 16 Nov 2008 15:46:54 -0800, rurpy wrote:
> 
>> For example, consider the two electrons around a helium nucleus. They
>> have the same mass, the same speed, the same spin, the same electric
>> charge, the same magnetic moment, they even have the same location in
>> space (technically, the same wave function).
> 
> By quantum mechanics (Pauli Exclusion principle), this is impossible.

Ah yes, you're right. Oops.

However, my point remains if you consider electrons in two atoms, and 
remove the "same location in space". 

[...]
>>> For example, you can define the value of None however you want, but it
>>> seems clear that it has (and needs) no intrinsic-value.
>> 
>> To me, that seems just as silly as arguing that zero is not a number,
> 
> To me, that distortion of his (and my) point is silly.  0 partipipates
> in numerous integer operations, whereas None participates in no NoneType
> operations.  (Neither has attributes.)  And that is the difference he is
> pointing at.

Why do you care about built-in NoneType operations? Why don't we count 
the infinite number of useful operations we can do to None that merely 
happen to not be built-in to the type?

We can convert None to a bool: bool(None)
We can append it to a list: alist.append(None)
We can convert it to a string: str(None), repr(None)
(In Python 2.6) We can ask how many bytes the None object uses.
We can ask the garbage collector how many objects refer to it: 
gc.get_referrers
We can count how many words have been written debating whether or not 
None is a value.

and so forth. These operations aren't methods on NoneType but that is not 
of any importance. The richness or poverty of methods in a class is 
irrelevant.

(I trust that nobody is going to raise yet another irrelevant detail and 
argue that since None is immutable, these operations don't actually do 
anything *to* None. Ints are immutable too, and nobody argues that int(5) 
has no value because operations on it don't do anything to it.)

It is useful and convenient to have "null values" like None, but it isn't 
useful to say that None is not a value. What does it gain you, other than 
losing the useful ability to say "the value of x is None"?



-- 
Steven
--
http://mail.python.org/mailman/listinfo/python-list

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

[rurpy]

On Nov 18, 10:22 am, Steve Holden <[EMAIL PROTECTED]> wrote
in thread "Python-URL! weekly Python news and links (Nov 17)":
> [EMAIL PROTECTED] wrote:
> [...]
>> One of the reasons I would like to formulate a good
>> model of an object's value and type is so that I could
>> try to offer something better.  Responses like yours
>> are significantly demotivating.
>
> And yet you argue when people try to explain to you that objects don't
> *have* values, objects *are* values. Objects have attributes, which are
> references to other values. One of an object's attributes is its type.

I am sorry for arguing with you.  I hear you
and others saying that the value (in the english
language sense of value) of an object *is* the
object.

But before I address that, I am a little confused
by what you wrote above.  Quoting the PLR again,
"Every object has an identity, a type and a value."
I presumed "value" to include attributes.  Are you
saying the correct statement in the PLR should have
been, "Every object has an identity, attributes, and
a value"?

The text below refers to identity, type and value
per the PLR, but you can substitute "attributes"
for type without affecting the logic.

Here is why I am having trouble accepting the
explanations you and others have kindly offered
me.  If values are objects then the words "object"
and "value" are synonymous, yes?  Fine, I can see
that could be a desirable thing.  Value is more
natural than object for people coming to Python,
for example.

But if you use the word value synonymously with
object, then the PLR statement that "an object
has identity, type, and value" is the same as "an
object has identity, type, and itself".  We know
the object is itself!　That's tautological.  So
what is the point of using the term value in the
definition of "object"?  You can just say "an object
has identity and type, and we will also use the word
value as a synonmym for object."

Other than cosmetics, the word "value" serves no
purpose and we can replace it with "object" wherever
we use it.  E.g. "the result of evaluating an
expression is a value.", "the result of evaluating
an expression is an object".  If value is the same
as object, then Python objects have only identity
and type.

But you know that's not true.  The types of int(2)
and int(3) are the same.  Is the difference in
behavior of the two objects due to their different
identities?!  Python knows the object at 0x260FF44
is a "2" object, and the object at 0x260FD60 is a
"3" solely by virtue of their addresses?

Of course not.
I hope you see why I find the "value is object"
to be an unacceptable explanation of Python
objects.

> You seem to be hunting for the ineffable
> "primitive value" that has no other attributes.
> Such a thing doesn't exist.

Sorry to argue again, but I explained (in a
previous post) why I believe such a thing does
exist.  Specifically, it is necessary to explain
the difference between the objects int(2) and
int(3).  Perhaps if you tell me exactly what
fault you find with that previous explanation
(in light of my problem with "values are objects"
above), I could reevaluate my understanding.
--
http://mail.python.org/mailman/listinfo/python-list

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

[greg]

Antoon Pardon wrote:

Call by value is officially defined in terms of assignment in
a context where assignments means copying and in a definition
of a specifix language.

You can't lift this part out of the definition of algol 60
and say it applies equally well in languages with different
assignment semantics.


But many other language designers, of both static and
dynamic languages, have done just that.

I'm not saying it *has* to be interpreted that way,
just that it *is* very often interpreted that way.
So you can't claim that it's not common usage.


If call by value is defined in terms of assignment regardless
of what the semantics of the assignment is then IMO call by
value is rather useless term


Not at all. It very concisely conveys how parameters
are passed, once you know how assignment works -- and
you need to understand that in any case.

--
Greg
--
http://mail.python.org/mailman/listinfo/python-list

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

[Aaron Brady]

On Nov 18, 2:55 pm, Terry Reedy <[EMAIL PROTECTED]> wrote:
> Steven D'Aprano wrote:
> > On Sun, 16 Nov 2008 15:46:54 -0800, rurpy wrote:
> > For example, consider the two electrons around a helium nucleus. They
> > have the same mass, the same speed, the same spin, the same electric
> > charge, the same magnetic moment, they even have the same location in
> > space (technically, the same wave function).
> > or that white pixels are "nothing" and black pixels are "something".
>
> This is a ridiculous attempt at ridicule;-)  Pixels have positions and 1
> to 4 graded attributes.  Completely different from None.

IINM if I'm not mistaken, portions of the retina are most excited in
the dark.

Same means one of two things.  Either share an identity (continuity of
form), or high degree of similarity in structure and composition.

On a physical level, the electrical states of bit circuits in memory
are very similar in two "equal" bytes.  Low voltage, low voltage, high
voltage.

Outside of the physical, the ideal, there is still such thing as
continuity.  We have a memory:

M= { 0: [ 1, 2 ],
 1: [ 1, 2 ] }

We can write an operation 'app( M, id, val )', which returns the
memory with the entry at id 'id' appended by 'val'.  The bracket
operation ( M[ id ] ) returns the entry of the memory at id 'id'.

>>> app( { 0: [ 1, 2 ], 1: [ 1, 2 ] }, 0, 3 )
{ 0: [ 1, 2, 3 ],
  1: [ 1, 2 ] }
>>> _[ 0 ]
[ 1, 2, 3 ]

Immutable types don't even need it.  Identity serves no additional
purpose to value.  That is, you can pick either tuple ( 1, 2 ), ( 1,
2 ) out of a bag with both in it, and operate.

With side-effects come mutable types, and identity and value diverge.
I think you can make a case that type is an entry in value, leaving
identity and value in general.  Then, identity just means, what
original expression an object is continuous with, and value is the
original expression plus subsequent mutations.

Logical matter can be created and destroyed, which clarifies some of
the issues about composition and identity.

Now go away, before I taunt you a second time.
--
http://mail.python.org/mailman/listinfo/python-list

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

[Robert Kern]

Terry Reedy wrote:

Steven D'Aprano wrote:

On Sun, 16 Nov 2008 15:46:54 -0800, rurpy wrote:


For example, consider the two electrons around a helium nucleus. They 
have the same mass, the same speed, the same spin, the same electric 
charge, the same magnetic moment, they even have the same location in 
space (technically, the same wave function).


By quantum mechanics (Pauli Exclusion principle), this is impossible.

 > They are identical in every
possible way. Are they the same electron, or two different electrons? 
What does the question even mean?


That you do not understand QM?

Photons, on the other hand, can be identical, hence lasars.

Matter is divided into leptons and bosons, individualists and 
communalists.  (I believe I have the name right.)


Fermions and bosons, actually.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

--
http://mail.python.org/mailman/listinfo/python-list

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

[Terry Reedy]

Steven D'Aprano wrote:

On Sun, 16 Nov 2008 15:46:54 -0800, rurpy wrote:


For example, consider the two electrons around a helium nucleus. They 
have the same mass, the same speed, the same spin, the same electric 
charge, the same magnetic moment, they even have the same location in 
space (technically, the same wave function).


By quantum mechanics (Pauli Exclusion principle), this is impossible.

> They are identical in every
possible way. Are they the same electron, or two different electrons? 
What does the question even mean?


That you do not understand QM?

Photons, on the other hand, can be identical, hence lasars.

Matter is divided into leptons and bosons, individualists and 
communalists.  (I believe I have the name right.)





For example, you can define the value of None however you want, but it
seems clear that it has (and needs) no intrinsic-value.


To me, that seems just as silly as arguing that zero is not a number,


To me, that distortion of his (and my) point is silly.  0 partipipates 
in numerous integer operations, whereas None participates in no NoneType 
operations.  (Neither has attributes.)  And that is the difference he is 
pointing at.




or that white pixels are "nothing" and black pixels are "something".


This is a ridiculous attempt at ridicule;-)  Pixels have positions and 1 
to 4 graded attributes.  Completely different from None.


tjr

--
http://mail.python.org/mailman/listinfo/python-list

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

[rurpy]

On Nov 17, 7:35 pm, Craig Allen <[EMAIL PROTECTED]> 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.
>
> I think the difference is concrete... an uninitialized variable in C
> has no value, I'd say, because the value it will have is
> indeterminate, it will be whatever happens to be sitting at that
> location in memory, inconsistent.  If that variable is initialized to
> some value representing "none", like NULL, then it has a consistent
> value of "none".  There is no way to have an uninitialized variable in
> python, so they are always consistently set, so they always have
> values.

I wrote "I don't see a difference between a "null value"
and not having a value" in the specific context of "what
constitutes an object?" considering the Python Docs
definition of object as identity, type, and value.  It
was that "value" (the characteristic of an object that
is left after you have considered id and type), that I
was referring to.  I still see no difference between a
"null value" and "has no value" in that context.
Nothing (directly) to do with memory, variables, C,
parameter passing, None, etc.

I realize in hightsight that the word "value" is too strongly
overloaded with pre-existing semantics for many people to
accept it being redefined with a specific meaning in the
limited context of a description of Python objects.  And it
was also pretty dumb of me to raise the issue in a contentious
thread about values in parameter passing.  Live and learn
--
http://mail.python.org/mailman/listinfo/python-list

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

[Steve Holden]

Steven D'Aprano wrote:
> On Mon, 17 Nov 2008 18:35:04 -0800, Craig Allen 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.
>>>
>>>
>> I think the difference is concrete... an uninitialized variable in C has
>> no value, I'd say, because the value it will have is indeterminate, it
>> will be whatever happens to be sitting at that location in memory,
>> inconsistent.  If that variable is initialized to some value
>> representing "none", like NULL, then it has a consistent value of
>> "none".  There is no way to have an uninitialized variable in python, so
>> they are always consistently set, so they always have values.
>>
>> ?
> 
> Well said.
> 
> I'd even go so far as to say that an uninitialized variable in C has a 
> random value, unless the compiler prevents you from accessing it. If the 
> compiler lets you (accidentally, I assume!) do something with an 
> uninitialized variable, then you're accessing whatever random value it 
> happens to get.
> 
> 
I think the correct terminology would be "the value of the variable is
undefined", meaning that each implementation is free to use whatever
behavior it likes.

Most C implementations will (I believe) end up with random data in those
variables rather than taking the time to initialize them to some
recognizable value (although some implementations have done that), and
this can be a fruitful source of non-repeatable segmentation faults and
inexplicable behaviors.

The nice thing about Python's ability to create variables on assignment
is that you will either get an UnboundLocalError or a NameError or an
AttributeError exception if you try to access a name that hasn't been
defined. This nicely parallels KeyError and IndexError behavior with
container objects.

regards
 Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/

--
http://mail.python.org/mailman/listinfo/python-list

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

[Antoon Pardon]

On 2008-11-12, greg <[EMAIL PROTECTED]> wrote:
> Steven D'Aprano wrote:
>
>> Why should anyone take the "Revised Report on the Algorithmic Language 
>> Algol 60" as the "official" (only?) definition of call-by-value for all 
>> languages everywhere?
>
> Since the term was more or less invented by the people
> who designed Algol, I thought it would be a good idea to
> find out, from as close to the source as possible, what
> *they* intended it to mean.

But you didn't try to find out their intention. You just took their
words and applied it in a different context. It isn't at all obvious
that placing their words in a context with different assignment
semantics would preserve their intend.

-- 
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list

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

[Steven D'Aprano]

On Sun, 16 Nov 2008 15:46:54 -0800, rurpy wrote:

> Since many responses to my definition of value raised similar points, I
> will try and respond generally here.
> 
> In hindsight, I should not have used the word "value"; it is far too
> overloaded with preexisting semantics for me to have attempted to
> redefine it, even if it is the word used (but not defined) in the Python
> Reference Manual.

It shouldn't need definition, since it already has a perfectly fine 
definition in the dictionary. It would only need an alternative 
definition if the dictionary one isn't suitable.


> Let me try again, in a slightly different way and using slightly
> different terminology in the hope we can avoid the fascinating but
> basically irrelevant philosophical digressions into form and ideal, the
> nature of nothingness, etc. :-)
> 
> Suppose I have two objects and want to know if they are the same or not.

Define "the same".

Pick up two bricks from the one batch. They have identical size and shape 
and colour, but any two bricks will have slight differences. Are they the 
same?



>  They are distinct objects so I know that their id()'s are different but
> that's not what I'm interested in.  Example
> 
>   class A(object): pass
> def __init__ (self): self.foo = 1
>   class B(object): pass
> def __init__ (self): self.foo = 2
>   a = A()
>   b = B()
> 
> How I can answer the question, "are the objects a and b the same or
> different"? I can look at every aspect of each object, looking for
> something that is different.

Well, sure, if you care *that much* about potentially trivial aspects. I 
have a ten dollar note with a spec of dirt on one corner, and a ten 
dollar note with a slightly larger spec of dirt on a different corner. 
I'd agree with you that they are not "the same" in every aspect, but 
they're the same in every way I care about.


> What are the aspects of the object that I can look at?
> 
> id(obj) will give me the identity but I know that will be different and
> so its irrelevant.

Philosophically, no, not irrelevant. You haven't explicitly defined "the 
same" in enough detail to make that call. Perhaps because the objects are 
in different locations (different IDs) is enough to make them different, 
even if everything else about them is identical.

For example, consider the two electrons around a helium nucleus. They 
have the same mass, the same speed, the same spin, the same electric 
charge, the same magnetic moment, they even have the same location in 
space (technically, the same wave function). They are identical in every 
possible way. Are they the same electron, or two different electrons? 
What does the question even mean?

My point is that as a philosophical position, identity may or may not 
count as "sameness". It depends on the circumstances.



> What else can we look at?  We can go through each
> attribute of the objects looking for an attribute that one has and the
> other doesn't, or for attributes of the same name that are different.
> 
> We look at .__class__, .__delattr__,  and so on and they are all the
> same until we come to .foo and note that a.foo and b.foo are different.
> One is an int(1) object, the other is an int(2) object.  So we can say
> that a and b are different.

Philosophically, sure, but practically, perhaps not. The foo attribute 
may be entirely irrelevant to your purposes, the equivalent of a random 
speck of dirt or a slight tear on a ten dollar note.

Luckily, Python doesn't try to guess whether differences are significant 
or not. You can override the __eq__ method on classes and choose for 
yourself what properties of a class are differences that make a 
difference and which are mere markers of no particular concern.

 
> Lets do the same with these two objects:
> 
>   a = int(2)
>   b = int(3)
> 
> When we do that, we find no difference!  Every attribute is the same in
> both a and b!  WTF!? 

That's because you haven't asked the objects themselves if they are the 
same. Not every aspect of objects are implemented as attributes.



> But we know when we call a's .__add__ method [*1]
> with the argument 1, we get a different result than when we call b's
> __add__ method with the argument 1.
> 
> Somehow, built into the internal representation of the int(2) object, is
> some representation of the number 2 and the int(2) object's __add__()
> method accesses this representation in order to decide that it has to
> create an int(3) object to return, rather than creating an int(47)
> object to return.
> But why don't we see this "2" when we examine the object?

Of course you do. Just look at the object and you will see it is a 2.



> Why isn't
> there a .value attribute or something holding 2?

Why should there be a value attribute? Python attributes are just a 
particular interface for accessing data. It's not the only possible 
interface.


> We look at everything we can 

You forgot to look at the object as a whole. Consider a pair of trousers. 
Y

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

[Aaron Brady]

On Nov 18, 2:21 am, Antoon Pardon <[EMAIL PROTECTED]> wrote:
> On 2008-11-12, greg <[EMAIL PROTECTED]> wrote:
>
> > Here is the definition of call-by-value from the
> > "Revised Report on the Algorithmic Language Algol 60"
> >:
>
> > 4.7.3.1. Value assignment (call by value). All formal parameters quoted in 
> > the
> > value part of the procedure declaration heading are assigned the values (cf.
> > section 2.8. Values and types) of the corresponding actual parameters, these
> > assignments being considers as being performed explicitly before entering 
> > the
> > procedure body. The effect is as though an additional block embracing the
> > procedure body were created in which these assignments were made to 
> > variables
> > local to this fictitious block with types as given in the corresponding
> > specifications (cf. section 5.4.5).
>
> > There you have it -- call by value is offially defined in
> > terms of assignment. There is no mention in there of copying.
>
> Call by value is officially defined in terms of assignment in
> a context where assignments means copying and in a definition
> of a specifix language.
>
> You can't lift this part out of the definition of algol 60
> and say it applies equally well in languages with different
> assignment semantics.
>
> If call by value is defined in terms of assignment regardless
> of what the semantics of the assignment is then IMO call by
> value is rather useless term and it would be better to talk
> about call by copy in the case of C, to make sure one understands
> the difference between what happens in C and what happens in
> other languages that also have "call by assignment" but behave
> very differently.
>
> --
> Antoon Pardon

I think Joe's argument was, C and Python can both be call-by-value, so
long as Python variables are construed to be pointers.  To him,
pointers are easy to understand, even for novices, and the copy
constructor for pointers is trivial.

Otherwise, C and Algol have different definitions of call-by-value,
and while Java might be Algol-call-by-value, Python is not C call-by-
value.  So, between C and Algol has majority and which has seniority
claim to the term?
--
http://mail.python.org/mailman/listinfo/python-list

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

[Antoon Pardon]

On 2008-11-12, greg <[EMAIL PROTECTED]> wrote:
> Here is the definition of call-by-value from the
> "Revised Report on the Algorithmic Language Algol 60"
>:
>
> 4.7.3.1. Value assignment (call by value). All formal parameters quoted in 
> the 
> value part of the procedure declaration heading are assigned the values (cf. 
> section 2.8. Values and types) of the corresponding actual parameters, these 
> assignments being considers as being performed explicitly before entering the 
> procedure body. The effect is as though an additional block embracing the 
> procedure body were created in which these assignments were made to variables 
> local to this fictitious block with types as given in the corresponding 
> specifications (cf. section 5.4.5).
>
> There you have it -- call by value is offially defined in
> terms of assignment. There is no mention in there of copying.

Call by value is officially defined in terms of assignment in
a context where assignments means copying and in a definition
of a specifix language.

You can't lift this part out of the definition of algol 60
and say it applies equally well in languages with different
assignment semantics.

If call by value is defined in terms of assignment regardless
of what the semantics of the assignment is then IMO call by
value is rather useless term and it would be better to talk
about call by copy in the case of C, to make sure one understands
the difference between what happens in C and what happens in
other languages that also have "call by assignment" but behave
very differently.

-- 
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list

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

[Steven D'Aprano]

On Mon, 17 Nov 2008 18:35:04 -0800, Craig Allen 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.
>>
>>
> I think the difference is concrete... an uninitialized variable in C has
> no value, I'd say, because the value it will have is indeterminate, it
> will be whatever happens to be sitting at that location in memory,
> inconsistent.  If that variable is initialized to some value
> representing "none", like NULL, then it has a consistent value of
> "none".  There is no way to have an uninitialized variable in python, so
> they are always consistently set, so they always have values.
> 
> ?

Well said.

I'd even go so far as to say that an uninitialized variable in C has a 
random value, unless the compiler prevents you from accessing it. If the 
compiler lets you (accidentally, I assume!) do something with an 
uninitialized variable, then you're accessing whatever random value it 
happens to get.


-- 
Steven
--
http://mail.python.org/mailman/listinfo/python-list

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

[Steven D'Aprano]

On Sun, 16 Nov 2008 23:34:58 -0500, Terry Reedy wrote:

> Steven D'Aprano wrote:


> class EqualsAll(object):
>> ... def __eq__(self, other):
>> ... return True
>> ...
> 5 == EqualsAll()
>> True
>> 
>> 
>> The methods of 5 don't even get called.
> 
> Why do you say that?  As I read the manual, type(left-operand).__eq__ is
> called first.

Ah, I could be confabulating that with arithmetic operators __add__ etc. 
It may be that comparisons use a different mechanism:

>>> 5 .__cmp__(EqualsAll())
Traceback (most recent call last):
  File "", line 1, in 
TypeError: int.__cmp__(x,y) requires y to be a 'int', not a 'EqualsAll'



-- 
Steven
--
http://mail.python.org/mailman/listinfo/python-list

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

[Aaron Brady]

On Nov 17, 8:35 pm, Craig Allen <[EMAIL PROTECTED]> 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.
>
> I think the difference is concrete... an uninitialized variable in C
> has no value, I'd say, because the value it will have is
> indeterminate, it will be whatever happens to be sitting at that
> location in memory, inconsistent.  If that variable is initialized to
> some value representing "none", like NULL, then it has a consistent
> value of "none".  There is no way to have an uninitialized variable in
> python, so they are always consistently set, so they always have
> values.
>
> ?

If he was dying, he wouldn't have bothered to carve 'Aaaauuuggg'.
He'd just say it.

#269 and counting!
--
http://mail.python.org/mailman/listinfo/python-list

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

[Craig Allen]

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

I think the difference is concrete... an uninitialized variable in C
has no value, I'd say, because the value it will have is
indeterminate, it will be whatever happens to be sitting at that
location in memory, inconsistent.  If that variable is initialized to
some value representing "none", like NULL, then it has a consistent
value of "none".  There is no way to have an uninitialized variable in
python, so they are always consistently set, so they always have
values.

?
--
http://mail.python.org/mailman/listinfo/python-list

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

[Terry Reedy]

[EMAIL PROTECTED] wrote:


Or one could adopt what Terry Reedy called a
4-aspect view: an object is identity, class,
value (or local-state or something) and
intrinsic-value.


What I specifically said is id, class, instance attributes, and private 
data.  So objects have only one, some only the other, some both, and 
some neither.  I also noted that the boundary between properties and 
instance methods of the class and attributes of the instance is somewhat 
flexible.


I think the important point is this.  In Python, objects are 
self-identifying bundles of information, which is to say, the bundle 
includes knowledge of the which universe of possible bundles the object 
comes from, where the universe includes a set of operations.  This is 
sometimes called RTTI -- run-time type information.  This is in contrast 
to other languages and signal-processors where information 
(bit-patterns) is usually *not* self-identifying, but the universe must 
be somehow enforced by a compiler or carried in the context.  In C, for 
instance, most types cannot have RTTI and RTTI is only required for 
unions.  Programmers can give structs a type field and that is how 
CPython implements PyObjects.


Terry Jan Reedy

--
http://mail.python.org/mailman/listinfo/python-list

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

[rurpy]

On Nov 16, 5:12 pm, Steve Holden <[EMAIL PROTECTED]> wrote:
>> The Python Reference Manual states that an object
>> consists of identity, type, and value.  "Identity"
>> seems to be non-controversial.
>>
>> Let's take "type" as meaning the attributes an
>> object inherits from it's class.  "value" is then
>> what is left: the object's local attributes and
>> the intrinsic-value described above.
>>
>> This seems to be the most common view of "value",
>> and similar to the one Fredrik Lundh takes in
>>   http://effbot.org/zone/python-objects.htm
>> which was pointed to in an earlier response
>> (he calls it "content")
>>
>> One could also take all attributes accessible
>> through obj (its class' attributes as well as
>> its local attributes) as "type" leaving only
>> intrinsic-value as "value".
>> This was the view I proposed.
>>
>> Or one could adopt what Terry Reedy called a
>> 4-aspect view: an object is identity, class,
>> value (or local-state or something) and
>> intrinsic-value.
>>
>> I don't understand Python well enough to defend
>> any of these descriptions (I now realize, despite
>> my previous postings to the contrary. :-)
>>
>> But what I do defend is the concept of intrinsic
>> value which I have not ever seen explicitly stated
>> anywhere and which clarifies a lot of things for me.
>>
>> For example, you can define the value of None
>> however you want, but it seems clear that it has
>> (and needs) no intrinsic-value.  Same with object().
>
> In that case I am not sure why this happens:
>
 a = object()
 b = object()
 a == b
> False

Who said the equality operator compares values
and that Python guarantees that it will always
return True if the values of its arguments are
the same?  You yourself point out below that this
is not true -- one can define "==" any way
one wishes.  If you can do so, can't the Python
language developers who implement "==" also do
so?  In fact they did do so in this case, they
compare id's.

So the next question is, "why not define value
equality (and implicitly values) to be whatever
"==" says it is"?  Well you could I suppose.  The
only hard constraints are that it be logically
consistent, and not lead to erroneous conclusions
about how Python works.  Soft constraints are that
in be easily understandable, and be intuitive.

I don't know if using "==" would meet the two hard
constraints, but it fails the two soft ones.
The context of the definition of "value" in the
Language Reference is where the basic properties
of objects are being described.  Why would one
want to make the definition of objects, the core
concept of Python, dependent on the behavior of
the "==" operator?

> Since those objects are of the same type, and since they have no
> "intrinsic value", it would seem you'd expect them to be equal. But they
> aren't, because (in the absence of an explicit equality test method)
> equality is tested for by testing for identity.

I would expect them to be equal, but apparently
Python's designers thought otherwise.  :-)
The "==" operator is designed to return results
that make the most sense (where sense is a
complicated function in the brains of the Python
developers.)  In calculating that return value,
Python need not return true for the "same"
intrinsic values any more than than an object
you define in Python has to.

>> I now understand why the only way to describe the
>> object int(2) is requires using str/repr whereas
>> with objects without an intrinsic value, I can
>> describe without needing str/repr.
>> I can think of expressions as always returning
>> objects, never "values".
>> Etc...
>>
>> So, is this point of view any more acceptable?
>>
> Why not just accept that equality is determined by
> the __eq__ method [2]?

I do.  But equality is not the same as "same-ness"
[Oh god, here comes another round of philosophical
discussion. :-)]

> Python can have objects that
> don't equal anything, even themselves,  objects that
> are equal to everything, and all definitions in between.
> So "equality" doesn't necessarily mean that the values
> are the same.

Right!  Which is exactly why equality is not the
right concept for trying to think about, "what are
the basic aspects of an object?" and "what is the
value of an object?".

> If objects have values that differ from the object itself, then aren't
> those values themselves objects? If so, what are the values of those
> objects?

Yes, the intrinsic value of a list object contains
(references to) other objects.  But note that I did
not claim to say *what* an instrinsic value was or
what it's value was, only that:
* it exists (in some but not all objects).
* builtin[*3] methods and functions can access
  it and use it to decide what they will return.
* that it is not accessible from Python language
  directly, only though the behavior of the those
  builtin methods/functions.[*4]
* That however you define "value" in the P.L.R.
  sense) it must include intrinsic value (if any)
So however P.L.R. "value"

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

[Terry Reedy]

Steven D'Aprano wrote:


Because of
Python's interpreted nature, names can't be compiled away as in C, they
need a concrete runtime existence, but does the language definition need
to assume that?


Of course. It wouldn't be Python if they didn't. However, remember that 
objects don't have names.


Actually, Python pretty much does compile away names for function 
bodies.  (They are replaced by array indexes.)  It only needs to 
manifest them for locals().  CPython Dis.dis also accesses them, but 
that is obviously implementation specific.  I suspect that the names are 
stored as C char sequences rather than as Python string objects unless 
and until the latter are needed for locals().


...

class EqualsAll(object):

... def __eq__(self, other):
... return True
...

5 == EqualsAll()

True


The methods of 5 don't even get called.


Why do you say that?  As I read the manual, type(left-operand).__eq__ is 
called first.



This of course is a special case, because 5 is a built-in,


If true, this would be CPython-specific optimization, not language 
definition.


> but in general, the result of x==y depends on  *both* x and y.

True.  But type(x) gets first crack at the answer.

...
You're assuming that == compares values, which is often a safe 
assumption, but not always.


The default is to compare by identity, so assuming otherwise is only 
safe when one knows the classes of x and y to over-ride the default.


Terry Jan Reedy

--
http://mail.python.org/mailman/listinfo/python-list

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

[Steve Holden]

[EMAIL PROTECTED] wrote:
> Since many responses to my definition of
> value raised similar points, I will try
> and respond generally here.
> 
> In hindsight, I should not have used the
> word "value"; it is far too overloaded with
> preexisting semantics for me to have attempted
> to redefine it, even if it is the word used
> (but not defined) in the Python Reference
> Manual.
> 
> Let me try again, in a slightly different
> way and using slightly different terminology
> in the hope we can avoid the fascinating
> but basically irrelevant philosophical
> digressions into form and ideal, the nature
> of nothingness, etc. :-)
> 
> Suppose I have two objects and want to
> know if they are the same or not.  They
> are distinct objects so I know that their
> id()'s are different but that's not what
> I'm interested in.  Example
> 
>   class A(object): pass
> def __init__ (self): self.foo = 1
>   class B(object): pass
> def __init__ (self): self.foo = 2
>   a = A()
>   b = B()
> 
> How I can answer the question, "are the
> objects a and b the same or different"?
> I can look at every aspect of each object,
> looking for something that is different.
> What are the aspects of the object that I
> can look at?
> 
> id(obj) will give me the identity but I know
> that will be different and so its irrelevant.
> What else can we look at?  We can go through
> each attribute of the objects looking for an
> attribute that one has and the other doesn't,
> or for attributes of the same name that are
> different.
> 
> We look at .__class__, .__delattr__,  and
> so on and they are all the same until we come
> to .foo and note that a.foo and b.foo are different.
> One is an int(1) object, the other is an int(2)
> object.  So we can say that a and b are different.
> 
> Lets do the same with these two objects:
> 
>   a = int(2)
>   b = int(3)
> 
> When we do that, we find no difference!  Every
> attribute is the same in both a and b!  WTF!?
> But we know when we call a's .__add__ method [*1]
> with the argument 1, we get a different result
> than when we call b's __add__ method with the
> argument 1.
> 
> Somehow, built into the internal representation
> of the int(2) object, is some representation of
> the number 2 and the int(2) object's __add__() method
> accesses this representation in order to decide that
> it has to create an int(3) object to return, rather
> than creating an int(47) object to return.
> 
> But why don't we see this "2" when we examine the
> object?  Why isn't there a .value attribute or
> something holding 2?  We look at everything we
> can but we can see no difference between the two
> objects, nothing that tells us that one is a 2,
> and the other a 3.
> 
> So clearly the 2-ness of int(2) is built into
> the object and is not visible *except* in it
> behavior.  The int(2)'s __add__ method knows
> how to access it, so do __repr() and __str__()
> and other methods.  But short of using those
> methods, there is no way for me (the programmer
> using Python) to access it.  The 2-ness is some
> sort of intrinsic property of the int(2) object.
> I will call it "intrinsic value".
> 
> The Python Reference Manual states that an object
> consists of identity, type, and value.  "Identity"
> seems to be non-controversial.
> 
> Let's take "type" as meaning the attributes an
> object inherits from it's class.  "value" is then
> what is left: the object's local attributes and
> the intrinsic-value described above.
> 
> This seems to be the most common view of "value",
> and similar to the one Fredrik Lundh takes in
>   http://effbot.org/zone/python-objects.htm
> which was pointed to in an earlier response
> (he calls it "content")
> 
> One could also take all attributes accessible
> through obj (its class' attributes as well as
> its local attributes) as "type" leaving only
> intrinsic-value as "value".
> This was the view I proposed.
> 
> Or one could adopt what Terry Reedy called a
> 4-aspect view: an object is identity, class,
> value (or local-state or something) and
> intrinsic-value.
> 
> I don't understand Python well enough to defend
> any of these descriptions (I now realize, despite
> my previous postings to the contrary. :-)
> 
> But what I do defend is the concept of intrinsic
> value which I have not ever seen explicitly stated
> anywhere and which clarifies a lot of things for me.
> 
> For example, you can define the value of None
> however you want, but it seems clear that it has
> (and needs) no intrinsic-value.  Same with object().

In that case I am not sure why this happens:

>>> a = object()
>>> b = object()
>>> a == b
False

Since those objects are of the same type, and since they have no
"intrinsic value", it would seem you'd expect them to be equal. But they
aren't, because (in the absence of an explicit equality test method)
equality is tested for by testing for identity.

> I now understand why the only way to describe the
> object int(2) is requires using str/repr whereas
> with obj

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

[rurpy]

Since many responses to my definition of
value raised similar points, I will try
and respond generally here.

In hindsight, I should not have used the
word "value"; it is far too overloaded with
preexisting semantics for me to have attempted
to redefine it, even if it is the word used
(but not defined) in the Python Reference
Manual.

Let me try again, in a slightly different
way and using slightly different terminology
in the hope we can avoid the fascinating
but basically irrelevant philosophical
digressions into form and ideal, the nature
of nothingness, etc. :-)

Suppose I have two objects and want to
know if they are the same or not.  They
are distinct objects so I know that their
id()'s are different but that's not what
I'm interested in.  Example

  class A(object): pass
def __init__ (self): self.foo = 1
  class B(object): pass
def __init__ (self): self.foo = 2
  a = A()
  b = B()

How I can answer the question, "are the
objects a and b the same or different"?
I can look at every aspect of each object,
looking for something that is different.
What are the aspects of the object that I
can look at?

id(obj) will give me the identity but I know
that will be different and so its irrelevant.
What else can we look at?  We can go through
each attribute of the objects looking for an
attribute that one has and the other doesn't,
or for attributes of the same name that are
different.

We look at .__class__, .__delattr__,  and
so on and they are all the same until we come
to .foo and note that a.foo and b.foo are different.
One is an int(1) object, the other is an int(2)
object.  So we can say that a and b are different.

Lets do the same with these two objects:

  a = int(2)
  b = int(3)

When we do that, we find no difference!  Every
attribute is the same in both a and b!  WTF!?
But we know when we call a's .__add__ method [*1]
with the argument 1, we get a different result
than when we call b's __add__ method with the
argument 1.

Somehow, built into the internal representation
of the int(2) object, is some representation of
the number 2 and the int(2) object's __add__() method
accesses this representation in order to decide that
it has to create an int(3) object to return, rather
than creating an int(47) object to return.

But why don't we see this "2" when we examine the
object?  Why isn't there a .value attribute or
something holding 2?  We look at everything we
can but we can see no difference between the two
objects, nothing that tells us that one is a 2,
and the other a 3.

So clearly the 2-ness of int(2) is built into
the object and is not visible *except* in it
behavior.  The int(2)'s __add__ method knows
how to access it, so do __repr() and __str__()
and other methods.  But short of using those
methods, there is no way for me (the programmer
using Python) to access it.  The 2-ness is some
sort of intrinsic property of the int(2) object.
I will call it "intrinsic value".

The Python Reference Manual states that an object
consists of identity, type, and value.  "Identity"
seems to be non-controversial.

Let's take "type" as meaning the attributes an
object inherits from it's class.  "value" is then
what is left: the object's local attributes and
the intrinsic-value described above.

This seems to be the most common view of "value",
and similar to the one Fredrik Lundh takes in
  http://effbot.org/zone/python-objects.htm
which was pointed to in an earlier response
(he calls it "content")

One could also take all attributes accessible
through obj (its class' attributes as well as
its local attributes) as "type" leaving only
intrinsic-value as "value".
This was the view I proposed.

Or one could adopt what Terry Reedy called a
4-aspect view: an object is identity, class,
value (or local-state or something) and
intrinsic-value.

I don't understand Python well enough to defend
any of these descriptions (I now realize, despite
my previous postings to the contrary. :-)

But what I do defend is the concept of intrinsic
value which I have not ever seen explicitly stated
anywhere and which clarifies a lot of things for me.

For example, you can define the value of None
however you want, but it seems clear that it has
(and needs) no intrinsic-value.  Same with object().
I now understand why the only way to describe the
object int(2) is requires using str/repr whereas
with objects without an intrinsic value, I can
describe without needing str/repr.
I can think of expressions as always returning
objects, never "values".
Etc...

So, is this point of view any more acceptable?

[*1] I took note  of Terry Reedy's point that
a.__add__(b) is really int.__add__ (a, b) but
since the two descriptions are isomorphic at
the level I am discussing, it seemed clearer
to leave class out of it.
--
http://mail.python.org/mailman/listinfo/python-list

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

[Steve Holden]

Steven D'Aprano wrote:
> On Sat, 15 Nov 2008 11:17:07 -0800, rurpy wrote:
[...]
>> * How can I find an object's value (if I don't believe
>>   .str(), .repr(), etc)?  Use gdb. :-)
> 
> I would say the object's value is the value, so if you have the object, 
> you have its value. 
> [...]

There's also the question, if you say that an object is different from
its value, of determining what the value's value is ...

regards
 Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/

--
http://mail.python.org/mailman/listinfo/python-list

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

[Steve Holden]

Steven D'Aprano wrote:
> On Sat, 15 Nov 2008 19:42:33 -0800, rurpy wrote:
[...]
>> But I propose that one can define value in a precise way that
>> captures what most people think of as value, and avoids confusing
>> objects (or references to them) and the value of objects.
> 
> Good luck. I think you're chasing your own shadow.
> 
Quite. The question naturally arises "Why would one want to?" This is
naturally followed by "How would it help if you did?"

Can't we just get back to programming? If this endless (sigh) discussion
actually helped anybody to understand how Python worked I could
sympathize with it.

regards
 Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/

--
http://mail.python.org/mailman/listinfo/python-list

Re: 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 +, 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  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 pr

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

[Steven D'Aprano]

On Sat, 15 Nov 2008 19:42:33 -0800, rurpy wrote:

> You are saying there is no objective definition of "value".  I disagree.
>  I think one can define value in a useful way that is precise,
> objective, and useful.

No, I'm not saying that there is no objective definition of value. I'm 
saying that the objective definition depends on the circumstances. I 
believe that it is foolish to try to avoid context-sensitivity in your 
definition of value.

It is possible though. You can consider everything which makes a thing 
different from another thing, but taken all the way that leads to 
deciding that this sentence:

"The cat sat on the mat."

does not have the same value as this sentence: 

"The cat sat on the mat."

because the second one comes further down this document. (I trust that 
you understand that sentences are compound symbols, expressions if you 
prefer.) I would argue that this is usually a silly distinction, since 
the position of a sentence in a document rarely makes a difference to the 
meaning (the value) of that sentence. But not always silly. Imagine the 
following:

"Harry pointed his massive gun at the fugitive.

'Do you feel lucky?'

[... much later on...]

Working undercover at the casino, Harry adjusted his uniform, brushed a 
speck of imaginary dust off the sleeve, and greeted the billionaire. 
'Good evening Sir, welcome to the Starlight Casino, your first drink is 
on the house. Could I interest you in a game of friendly poker? Do you 
feel lucky?'"

Is there any doubt that the same symbol can denote a different meaning (a 
value) under different circumstances?



>> I would say that the "everything of interest" I referred to above is
>> the empty set: object() has little or no state. But of course having no
>> state is itself a state, in the same way that 0 is a perfectly good
>> integer.
> 
> "interest" is pretty subjective, isn't it?

Of course not. If we agree that we want something that undergoes integer 
addition as defined by mathematicians, there's nothing subjective about 
that. That will immediately rule out vast numbers of values: None, dicts, 
lists, strings, and so forth. But it still allows floats, ints, mpz 
objects, etc., and in principle we're indifferent to which of them we 
get. We may choose to arbitrarily convert objects from one type to 
another, whatever is convenient, so long as they can be added together. 
Any other property of these types is a red stripe, to be kept if 
convenient, discarded if needed, but always ignored.



> In the My_int example above,
> is the .foo attribute of interest or not?  How would I decide?

That depends on what you wish to do with the object. If you just want to 
add it to an int, then it is of no interest. It's a red stripe. But if 
you want to pass it on to another function which may treat the foo 
attribute as significant, then you can't afford to just throw it away. In 
other words, you care about the attribute, even if you aren't using it 
yourself.



>> 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 my definition of value, the answer is an unambiguous yes.

But that implies that you should be able to use s2 anywhere that you can 
use s1, and that's clearly not true:

assert len(s2.upper()) == len(s2)

Since you can't use s1 and s2 in the same places, how can you justify 
saying the have the same value?

I have an answer to that: if I don't care about upper(), then I'm happy 
to consider them to have the same value. If I do care about the invariant 
above, then I can't.


 
>> Using definition (1) above, we can see that the names s1 and s2 refer
>> to different objects, so the names have different values.
> 
> No, they refer to different objects.  

"No"? That's what I said.


> The object str("Norwegian Blue")
> has a value, tucked away inside it somewhere, of some implementation
> defined bits that encode "Norwegian Blue".
> String("Norwegian Blue") is a subclass of str and has the same value. 

Sure, in the specific example I gave, but in general this is not 
necessarily the case. Consider this fact: every string can be represented 
by a sequence of bytes. A byte can be considered a digit in base 256. 
"Norwegian Blue" considered as a number in this fashion is 
1590857700756072424900433200051557. With sufficient effort, I could 
inherit from long, instead of str, and duplicate the exact behaviour as 
str. Subclassing is a red-herring.



> (Actually, we don't really care about bit patterns, it is enough to
> declare that the values stored in the objects are the same because
> that's how the language is defined.) If they appear different when
> .upper() is called, it is because the two types (i.e. behaviors) are
> different.

But behaviour defines what we interpre

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

[Arnaud Delobelle]

Derek Martin <[EMAIL PROTECTED]> writes:

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

None is an 'value' which is intended to denote the absence of any
'value' *other than None*.

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

I would like to have a word with your maths teacher!  There are plenty
of uses for 0, most of which are unrelated to 'nothingess'.  E.g. 0 is
*greater* than -1 so it must be something.

-- 
Arnaud
--
http://mail.python.org/mailman/listinfo/python-list

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

[Derek Martin]

On Sun, Nov 16, 2008 at 09:30:45AM +, Arnaud Delobelle wrote:
> [...]
> > If you like, you could think of the value of an object as the set of
> > all possible values to which the object may evaluate in every possible
> > context, given a particular state of the object.
> 
> This definition looks a bit circular to me ;)

Why, because it has the word "value" in the definition?  It's not
circular.  The thing being defined is "value of an object".  The word
"value" has a pre-existing well-understood natural language definition.

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



pgpJNlOWqxfA7.pgp
Description: PGP signature
--
http://mail.python.org/mailman/listinfo/python-list

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

[Arnaud Delobelle]

Derek Martin <[EMAIL PROTECTED]> writes:

> On Thu, Nov 13, 2008 at 11:58:18AM -0800, [EMAIL PROTECTED] wrote:
>> I have yet to see any reasonable definition of a Python value in the
>> Python docs or elsewhere, despite the fact that a value is one of
>> the three defining characteristics of an object, a central concept
>> in Python.
>
> Why does it need to be defined in the Python docs?  Is this really
> even an important question to answer?  Are you unable to write correct
> functional programs in Python without having it answered?  I suspect
> it's not an issue...
>
> Let's assume for the moment that it is, though.  The term "value"
> already has a meaning... the one ascribed to it by its use in natural
> language.  One on-line dictionary includes this among its definitions:
>
>   magnitude; quantity; number represented by a figure, symbol, or the
>   like: the value of an angle; the value of x; the value of a sum.
>
> It seems clear that this, or something extremely close to this, is
> what is meant in the Python docs by the unqualified use of the term.

I reiterate that IMO the 'value' of an object is not really a useful
concept.

E.g. think of the integer 3.  It has a representation ('3'), it compares
to other objects (via int.__eq__, int.__lt__, etc), you can perform
arithmetic operations on it (via int.__add__, int.__sub__, etc), etc.
What more would you want to know about it?

[...]
> If you like, you could think of the value of an object as the set of
> all possible values to which the object may evaluate in every possible
> context, given a particular state of the object.

This definition looks a bit circular to me ;)

-- 
Arnaud
--
http://mail.python.org/mailman/listinfo/python-list

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

[Derek Martin]

On Sun, Nov 16, 2008 at 08:38:25AM +, Steven D'Aprano wrote:
> I believe that the language reference says that objects have an identity, 
> a type and state, but I'm too lazy too look it up. I'd be happy with that 
> definition.

They do indeed say value, not state.  As I said in a different
message, I'd agree that it's not a very clear definition.

> > I don't see how saying "the value of an object is itself" is
> > particularly useful.  We already have a word for what an object is, it
> > is "object". :-) 
> 
> I didn't say it was very useful. As far as I'm concerned, asking what the 
> value of an object is is not a useful question.

Now we agree. :)

> > The result of x==y depends solely on the behavior (methods) of x.
> 
> Nonsense.

It's wrong to say *solely*, but the value of x==y does indeed depend
on the behavior of the methods.

> I think the value of x is "a thing which claims to be equal to
> everything on Tuesdays, and equal to nothing every other day".

That isn't its *VALUE* -- it's its *IDENTITY*.  My weight is not my
identity... but in a certain context, it could be considered my value.
 
-- 
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D



pgpVW1VzHngyK.pgp
Description: PGP signature
--
http://mail.python.org/mailman/listinfo/python-list

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

[Derek Martin]

On Sun, Nov 16, 2008 at 06:06:20AM +, 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/

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

[Steven D'Aprano]

On Sat, 15 Nov 2008 19:41:20 -0800, rurpy wrote:

>> I prefer another definition of object: an object *is* a value, rather
>> than *has* a value. That value consists of identity, type (or class),
>> and everything else of interest which is sometimes also called "value".
>> Since identity is usually unimportant, and type is assumed from
>> context, we can often get away with stating that the "everything else
>> of interest" is *the* value.
> 
> The Python Lang. Ref. says:
>   object = identity + type + value

I believe that the language reference says that objects have an identity, 
a type and state, but I'm too lazy too look it up. I'd be happy with that 
definition.


> You are defining objects as:
>   object = identity + type + (object - (identity + type)) value = object
>   - identity = type + (object - (identity + type))
> 
> Seems to me it is easier just to give the "object - (identity + type)"
> part a name, say, "value". :-)

I would call that state. Then I would say that the value of an object is 
the object's state, possibly with the identity and/or type if they are 
important in context.


> I also question, "type is assumed from context".  To me, type is very
> objective: it is the set of methods and other attributes that define the
> behavior of the object.

Sure. But that doesn't contradict my statement that often type can be 
assumed from context, although I didn't explain myself terribly well. 
What I meant was that the range of types we accept as having the same 
value will depend on what we want to do with the values. That's duck-
typing: if we only care that a thing has webbed feet, then everything 
else about the various waterfowl is mere decoration. The only thing of 
significance is the presence or absence of webbed feet, and in principle 
we are indifferent as to whether we get Goose(3) or Duck(3) or Swan(3), 
or even Pelican(3). Other aspects of the object's behaviour (its type) 
such as whether they honk, quack, or hiss, are irrelevant.

>From a philosophical position, Goose(3) has a different value to Duck(3), 
and I have no problems with saying so. But in a practical sense, if I 
don't care what sort of web-footed thing I get, then everything else is a 
mere red stripe, an arbitrary decoration or implementation detail.


 
>> I usually talk about one of the three levels of value:
>>
>> (1) The value of the NAME (or variable) x is the object int(3); that
>> is, the thing denoted by the symbol x is the object int(3).
> 
> OK, but a name is a rather abstract concept, is it not?  

Not at all, it is a fundamental part of Python, analogous to variable.


> Because of
> Python's interpreted nature, names can't be compiled away as in C, they
> need a concrete runtime existence, but does the language definition need
> to assume that?

Of course. It wouldn't be Python if they didn't. However, remember that 
objects don't have names.


> And per innumerable previous discussions, is it not preferable to "bind
> the name to an object" sidestepping any need for "value" in this
> context?

Nevertheless, people will insist on asking "what's the value of x?" and 
expect to get the answer 3 if they have previously executed x = 3. I 
don't see that this is a problem. The name x is a symbol, and it denotes 
the object 3. Where's the problem in using the term value?


 
>> (2) The value of the OBJECT int(3) is the specific concrete
>> instantiation that makes it the thing that it is rather than another
>> thing (a complicated way of saying that the value of an object is
>> itself); that is, the thing denoted by the symbol int(3) is some
>> specific byte pattern in memory which causes that object to be int(3)
>> rather than some other object.
> 
> I don't see how saying "the value of an object is itself" is
> particularly useful.  We already have a word for what an object is, it
> is "object". :-) 

I didn't say it was very useful. As far as I'm concerned, asking what the 
value of an object is is not a useful question.



> The point of the word "value" is to describe, in a
> general way, without defining implementation details, what you describe
> as "some specific byte pattern in memory which causes that object to be
> int(3) rather than some other object" and does not mix in other
> bit-pattern differences, such as differences in type which are not
> relevant to what we intuitively think of as "value".
> 
>> To put it another way, the value of that object is whatever properties
>> of the object distinguish it from any other the whole number 1.

Sorry, that sentence is incoherent. What I meant to write was:

"To put it another way, the value of that object is whatever properties 
of the object distinguish it from anything other than the whole number 1."

 
> This is saying something different, that the value of an object depends
> on how it's type relates to some non-programming-language concept
> ("whole numbers" in this case) that the object attempts to model.

Try as we might, we can't entirely 

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

[Derek Martin]

On Thu, Nov 13, 2008 at 11:58:18AM -0800, [EMAIL PROTECTED] wrote:
> I have yet to see any reasonable definition of a Python value in the
> Python docs or elsewhere, despite the fact that a value is one of
> the three defining characteristics of an object, a central concept
> in Python.

Why does it need to be defined in the Python docs?  Is this really
even an important question to answer?  Are you unable to write correct
functional programs in Python without having it answered?  I suspect
it's not an issue...

Let's assume for the moment that it is, though.  The term "value"
already has a meaning... the one ascribed to it by its use in natural
language.  One on-line dictionary includes this among its definitions:

  magnitude; quantity; number represented by a figure, symbol, or the
  like: the value of an angle; the value of x; the value of a sum.

It seems clear that this, or something extremely close to this, is
what is meant in the Python docs by the unqualified use of the term.

So, then, what is the value of a Python object?  As has been alluded by
others, it is not possible to formally define or enumerate what such a
value is, in general terms, because the term "object" refers to 
to a thing with neither a deterministic nor static identity; in the
abstract an object has no inherent or intrinsic value.  

The best you can hope to do is define it in context.  To illustrate:
In natural language and the physical world, an object has any number
of values; for example a book has a title, a topic, a weight, a
height, a length, a width, a page count, a word count, a purchase
price, a printing cost, a number of copies sold, a profit per unit
sold, etc. to the limits of your imagination regarding ways to
describe books.  Which of these is its "value" depends upon the
context in which you are discussing the book.  To the reader, the
value is the price he pays for the book, or perhaps some measure of
the enjoyment he derives from reading it (possibly the amount he would
be willing to pay to buy it).  To the seller, the value is perhaps
best represented by the profit per unit sold.  To the publisher's
shipper (think FedEx), the value might best be described in terms of
its weight...

Just as in the physical world, in Python an object can be defined such
that it evaluates to different values in different contexts, even
though its state may not have changed between those different
contexts.  Therefore the value of an object is dependent upon its data
attributes AND its behaviors defined as methods, as well as the
context in which it is accessed, and is the value to which the object
evaluates in a given expression or context.

If you like, you could think of the value of an object as the set of
all possible values to which the object may evaluate in every possible
context, given a particular state of the object.

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



pgpbIUrXOwI9A.pgp
Description: PGP signature
--
http://mail.python.org/mailman/listinfo/python-list

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

[Steven D'Aprano]

On Sat, 15 Nov 2008 11:17:07 -0800, rurpy wrote:

>>> * 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: mpz(3) where mpz is multi-precision int class with same set of
>> possible values as Python ints.
> 
> The argument to mpz() is int(3).

Does mpz take string arguments? If it doesn't, it is easy to imagine a 
version that does.

mpz("3")



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

Ah, the Medieval concept of numbers. Of course it's very much older than 
Medieval. Roman and Greek mathematics was bedeviled by their philosophy 
that one is the smallest number. (In fact, some early mathematicians 
argued that *two* was the smallest number, for the reason that if you 
have only one sheep (say) it would be unnatural to say that "I have a 
number of sheep") 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.

If you wish to say that null values aren't values at all, you will find 
that you have many conceptual difficulties. Given:

x = 5
y = 5
z = x - y

you will be forced to say that x and y have values but z does not. But 
that doesn't mean that z is undefined -- it means that z is defined and 
has no value, which makes communication very much more complicated. You 
are forced to say things like:

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

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.


 
>> Still, numbers, characters, and collections thereof of what code is
>> usually about.
> 
> Yes, which is why we have int, str, and list classes which, unlike some
> others, can have values.

What classes do you think have no values?


 
[snip]
>>> * 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?  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.

> a = int(3)
> b = My_int(3)


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.

(Actually, that's not quite true: by necessity pickle *cannot* treat 
identity as important. If your application requires object identity to be 
persistent over execution session, you can't do so in Python. Hence 
pickle and related serialisers can afford to ignore identity.)

Given input of b, the round-trip of pickle/unpickle must return an object 
with a foo attribute. If the round-trip merely returns a My_int instance 
without the foo attribute, we would rightly consider it a bug, that the 
output doesn't have the same value as the input. Likewise if it returned 
int(3) instead of My_int(3).

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.

In general, Python makes the fewest possible promises of that nature. If 
you want to treat foo as having a significant part of the value of b, 
then you need to deal with it yourself, perhaps by writing __add__ and 
__radd__ methods to My_int.

But from a philosophical position, as opposed to a practical one, of 
course a and b have different values. The value of a is (the integer 3), 
and the value of b is (the integer 3 together with an attribute foo), 
even if foo is a mere decoration, a stripe of red paint on an otherwise 
identical object. Since they are different, the objects a and b have 
different values. This is a valid philosophical position, although in 
practice we often lower our expectations, especially when duck-typing. We 
don't care about the red stripe or not, and so we are indifferent to 
whether we get int(3) or My_int(3).


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

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

[rurpy]

[Tried multiple times to post this but Google errors
out so will try posting in two parts... this is part 2]
On Nov 14, 11:51 pm, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
> On Fri, 14 Nov 2008 22:56:52 -0500, Terry Reedy wrote:
>> [EMAIL PROTECTED] wrote:
>>> On Nov 13, 4:53 pm, Terry Reedy wrote:
 [EMAIL PROTECTED] wrote:

>>> * 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
>> Yes: mpz(3) where mpz is multi-precision int class with same set of
>> possible values as Python ints.
>>
>> ??? 3.0
>> ??? Fraction(3,1)
>>
>> While Python sees these as *equal*, one could say they are not the same
>> because they indicate members of different (non-isomorphic) universes.
>
> Whether we wish to say that mpz(3) has the same value as int(3) depends
> on what we care about, and we only care about that because our data types
> are leaky abstractions. In principle, we should be indifferent to whether
> x is int(3), float(3.0), mpz(3), or any other instantiation of the
> abstract numeral three. In practice, we're not indifferent: we prefer
> ints for mpz objects for some purposes, but not for others. If we care
> about the specifics, then we might say they have different values
> (because they have different types, and therefore different
> characteristics). If we care only about the thing they represent, the
> abstract number three, then we'd say that they have the same value.

You are saying there is no objective definition
of "value".  I disagree.  I think one can define
value in a useful way that is precise, objective,
and useful.

>>> * Do all objects have values? (Ignore the Python
>>>  docs if necessary.)
>>
>> If one allows null values, I am current thinking yes. Still, numbers,
>> characters, and collections thereof of what code is usually about.
>
> I would say that all objects *are* values, rather than *have* values. The
> value of None is the object None, which is a concrete instantiation of a
> selected subset of behaviour of the null object pattern.
>
>>> * What is the value of object()?
>>
>> Essentially none, other than bool(object()) == True. Ditto for None,
>> other than bool(None) == False. Otherwise, None and object convey no
>> information.
>
> I would say that the "everything of interest" I referred to above is the
> empty set: object() has little or no state. But of course having no state
> is itself a state, in the same way that 0 is a perfectly good integer.

"interest" is pretty subjective, isn't it?  In the
My_int example above, is the .foo attribute of interest
or not?  How would I decide?  How would you decide?
I was also going to ask about changing methods, but I
see you consider that below.

> In practice, I'd say that object() is one of those cases where we should
> include identity in the value. Although we're indifferent as to *which*
> object() instance we get, once we've got one, we care whether other
> instances are the same instance or different ones. Imagine that object()
> keeps a cache of instances, and returns one instead of creating a brand
> new object. We don't care which instance we get, or even whether it comes
> from the cache or is created fresh. But once we have one, we care about
> the identities of others:
>
> special = object()  # we don't care which object instance we get
> if special is some_other_instance():
> print "Match!"
>
>>> * 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.  In those cases in which the class
>> of an object can be and is changed to another class, the interpretation
>> of the value/info of the instance could change and one might claim that
>> the effective value and hence the value of the object has changed and
>> hence the answer could be Yes.  But this is extremely rarely done and I
>> could claim that this is a shortcut for creating a new object and
>> deleting the old.
>
> 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 my definition of value, the answer is
an unambiguous yes.

> Using definition (1) above, we can see that the names s1 and s2 refer to
> different objects, so the names have different values.

No, they refer to different objects.  The object
str("Norwegian Blue") has a value, tucked away
inside it somewhere, of some implementation defined
bits that encode "Norwegian Blue".

String("Norwegian Blue") is a subclass of str
and has the same value.  (Actually, we don't really
care about bit patterns, it is enough to declare
that the values stored in the objects are the same
because that's how the language is defined.)
If they app

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

[rurpy]

[Tried multiple times to post this but Google errors
out so will try posting in two parts... this is part 1]

On Nov 14, 11:51 pm, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
> On Fri, 14 Nov 2008 22:56:52 -0500, Terry Reedy wrote:
>
>> [EMAIL PROTECTED] wrote:
>>> On Nov 13, 4:53 pm, Terry Reedy wrote:
 [EMAIL PROTECTED] wrote:

> I have yet to see any reasonable definition of a Python value in the
> Python docs or elsewhere, despite the fact that a value is one of the
> three defining characteristics of an object, a central concept in
> Python.
 I noticed too.  My try:

 The value of an object is the information that the object represents
 (or that is stored with the object) that the interpreter uses to
 compute the value of a new object when you use the object in an
 expression.  For number objects, the number value.  For collection
 objects, the objects collected. For functions, the signature and
 function performed when called.

 How is that?
>>>
>>> I am starting with the idea that "value" is what we call whatever it is
>>> that is the difference between, for example, the objects int(3) and
>>> int(4).  While your definition seems to be saying something similar it
>>> does not seem very precise.
>>
>> I think necessarily so, or rather, it can only be specific for each
>> class.  In the formulation: an object has identify, class, and value,
>> class and value are separated.  Others have said that type/class is a
>> universe of possible values and operations on those values.  Each
>> instance has a particular value. 'Universe of possible values' is vague
>> until one gets specific.  For some classes, the possible values are
>> rather complex.

I will presume you read my response to Terry Reedy so
I won't repeat everything I said there here.

> I prefer another definition of object: an object *is* a value, rather
> than *has* a value. That value consists of identity, type (or class), and
> everything else of interest which is sometimes also called "value". Since
> identity is usually unimportant, and type is assumed from context, we can
> often get away with stating that the "everything else of interest" is
> *the* value.

The Python Lang. Ref. says:
  object = identity + type + value
You are defining objects as:
  object = identity + type + (object - (identity + type))
  value = object - identity = type + (object - (identity + type))

Seems to me it is easier just to give the "object - (identity + type)"
part a name, say, "value". :-)

I also question, "type is assumed from context".  To
me, type is very objective: it is the set of methods
and other attributes that define the behavior of the
object.

> I usually talk about one of the three levels of value:
>
> (1) The value of the NAME (or variable) x is the object int(3); that is,
> the thing denoted by the symbol x is the object int(3).

OK, but a name is a rather abstract concept, is it
not?  Because of Python's interpreted nature, names
can't be compiled away as in C, they need a concrete
runtime existence, but does the language definition
need to assume that?

And per innumerable previous discussions, is it not
preferable to "bind the name to an object" sidestepping
any need for "value" in this context?

> (2) The value of the OBJECT int(3) is the specific concrete instantiation
> that makes it the thing that it is rather than another thing (a
> complicated way of saying that the value of an object is itself); that
> is, the thing denoted by the symbol int(3) is some specific byte pattern
> in memory which causes that object to be int(3) rather than some other
> object.

I don't see how saying "the value of an object is
itself" is particularly useful.  We already have a
word for what an object is, it is "object". :-)
The point of the word "value" is to describe, in
a general way, without defining implementation
details, what you describe as "some specific byte
pattern in memory which causes that object to be
int(3) rather than some other object" and does not
mix in other bit-pattern differences, such as
differences in type which are not relevant to what
we intuitively think of as "value".

> To put it another way, the value of that object is whatever properties of
> the object distinguish it from any other the whole number 1.

This is saying something different, that the value
of an object depends on how it's type relates to
some non-programming-language concept ("whole numbers"
in this case) that the object attempts to model.

> Since
> identity is (usually) unimportant for distinguishing one object from
> another (we usually care whether x==y, not whether x is y) the identity
> is not part of the value.

The result of x==y depends solely on the behavior (methods)
of x.  (To be anal, the behavior of x might be to delegate
calculating the result to y).  That behavior (if reasonable)
will take into consideration the "value"s of x and y.  This
seems to imply that "valu

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

[rurpy]

On Nov 15, 4:12 pm, Terry Reedy <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>> On Nov 14, 8:56 pm, Terry Reedy <[EMAIL PROTECTED]> wrote:
...snip...
 * 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.

So if method .foo() is an instance attribute it
is part of the object's value, but if it is part
of the object's class, it is part of the object's
behavior?  Even though calling obj.foo() causes
exactly same results?  I can see that a case can
be made for defining things that way, but it doesn't
seem desirable.

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

Or: object attributes are considered together with class
attributes to define an object's behavior leading to:
obs have 3 aspects -- id, behavior, and value.
(The definition of "type" might be stretched a little to
make it synonymous with behavior.)

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

But raising an exception is a aspect of behavior,
not of value.

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

It seems to me that what I think of as "value" is
indeed a sort of private attribute (that's how I
am trying out thinking of it.)  But it is its
privateness, its totally different way of getting
created, used, and changed, that is the very thing
that makes it unique and worthy of getting it's
own name.

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

Which seems to me to most closely match the intuitive
sense of value.  To me it is intuitive that int(3)
and subclass_of_int(3) have the same value, 3.  To
learn that their values are different because one
has an attribute the other didn't, or because the
values in a common (in name) attribute were different,
would be very surprising to me.

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

I can see viewing functions in general as a mapping
of arguments values to results in the context of describing
algorithms.  I am not sure it is the best way to view
them in the context of how objects are manipulated in
the Python runtime environment.

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

If attributes are part of an object's value, that
universe is effectively infinite, isn't it?  For
the vast majority of objects (those created in
Python from a class not designed to impose bondage
and discipline by using slots for example) I can
add any attributes I wish with any values I wish
to an object.  So class doesn't really determine
much under that definition, does it?

>  'Functions'
> includes all types of syntactic expressions.

Doesn't that use of the word "function" conflict
with the already established use of "function"
in Python.  I.e., I think of functions as just
another object, albeit one with a code attribute
that the Python VM knows how to call.

I think of evaluation of expressions as a series
of method (or other callable) executions, each
returning an object that is used in the next step
of the series.

> value: determine specific result when used as argument in functions

You are prepa

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

[Terry Reedy]

[EMAIL PROTECTED] wrote:

On Nov 14, 8:56 pm, Terry Reedy <[EMAIL PROTECTED]> 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

--
http://mail.python.org/mailman/listinfo/python-list

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

[rurpy]

On Nov 14, 8:56 pm, Terry Reedy <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>> On Nov 13, 4:53 pm, Terry Reedy wrote:
>>> [EMAIL PROTECTED] wrote:
>>>
 I have yet to see any reasonable definition of a Python
 value in the Python docs or elsewhere, despite the fact
 that a value is one of the three defining characteristics
 of an object, a central concept in Python.
>>> I noticed too.  My try:
>>>
>>> The value of an object is the information that the object represents (or
>>> that is stored with the object) that the interpreter uses to compute the
>>> value of a new object when you use the object in an expression.  For
>>> number objects, the number value.  For collection objects, the objects
>>> collected. For functions, the signature and function performed when called.
>>>
>>> How is that?
>>
>> I am starting with the idea that "value" is what we call
>> whatever it is that is the difference between, for example,
>> the objects int(3) and int(4).  While your definition
>> seems to be saying something similar it does not seem
>> very precise.

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

> I think necessarily so, or rather, it can only be specific for each
> class.  In the formulation: an object has identify, class, and value,
> class and value are separated.  Others have said that type/class is a
> universe of possible values and operations on those values.  Each
> instance has a particular value. 'Universe of possible values' is vague
> until one gets specific.  For some classes, the possible values are
> rather complex.
>
>> How would I use your definition to answer the following
>> questions?
>>
>> * How does an object get a value?
>
> A Python interpreter, human or electronic, creates objects with values
> as directed by Python code.  How it does so is its private secret ;-).
> The directive code includes literals, expressions, and some statements.

OK.

>> * 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))
Rephrasing: is possible to create an object that has
a value that is the same as int(3) without somehow
using a method of the int class (or sub/super-class)
in its construction?
I think it is not possible in the Python language.
That is one could in theory have a float method,
to_int(), but it could not be implemented in the
Python language (as opposed to implemented in the
Python implementation) without using int(), or some
other callable that uses int().

> Yes: mpz(3) where mpz is multi-precision int class with same set of
> possible values as Python ints.

The argument to mpz() is int(3).

> ??? 3.0
> ??? Fraction(3,1)
>
> While Python sees these as *equal*, one could say they are not the same
> because they indicate members of different (non-isomorphic) universes.

At this point, I would so say.

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

> Still, numbers, characters, and collections thereof of what code is
> usually about.

Yes, which is why we have int, str, and list classes
which, unlike some others, can have values.

>> * What is the value of object()?
>
> Essentially none, other than bool(object()) == True.
> Ditto for None, other than bool(None) == False.
> Otherwise, None and object convey no information.

A method/function can use whatever characteristic of
its arguments that it wants.  For example, id() pays no
attention to the value of its argument, only its identity.
So we can say that the bool class constructor returns
True for all object except None.  Since None is a
singleton, bool() can identify it by identity, without
consideration of it's (non-existent I propose) value.

>> * 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?  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)

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

> of an object can be and is changed to another class, the interpretation
> of the value/info of the instance could change and one might claim that
> the effective value and hence the value of the object has changed and
> hence the answer could be Yes.  But this is extremely rarely done and I
> could claim that this is a shortcut for creating a new object and
> deleting the old.
>
>> 

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

[Arnaud Delobelle]

[EMAIL PROTECTED] writes:

> I have yet to see any reasonable definition of a Python
> value in the Python docs or elsewhere, despite the fact
> that a value is one of the three defining characteristics
> of an object, a central concept in Python.

I don't remember how the expression 'object value' is used in the Python
docs (and python.org is unreachable from where I am at the moment) but I
know that I don't need such a concept to understand, or code in, Python.

Objects have a type, may have attributes, and that's it!

-- 
Arnaud
--
http://mail.python.org/mailman/listinfo/python-list

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

[Aaron Brady]

On Nov 15, 12:51 am, Steven D'Aprano <[EMAIL PROTECTED]
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.
--
http://mail.python.org/mailman/listinfo/python-list

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

[Steven D'Aprano]

On Fri, 14 Nov 2008 22:56:52 -0500, Terry Reedy wrote:

> [EMAIL PROTECTED] wrote:
>> On Nov 13, 4:53 pm, Terry Reedy wrote:
>>> [EMAIL PROTECTED] wrote:
>>>
 I have yet to see any reasonable definition of a Python value in the
 Python docs or elsewhere, despite the fact that a value is one of the
 three defining characteristics of an object, a central concept in
 Python.
>>> I noticed too.  My try:
>>>
>>> The value of an object is the information that the object represents
>>> (or that is stored with the object) that the interpreter uses to
>>> compute the value of a new object when you use the object in an
>>> expression.  For number objects, the number value.  For collection
>>> objects, the objects collected. For functions, the signature and
>>> function performed when called.
>>>
>>> How is that?
>> 
>> I am starting with the idea that "value" is what we call whatever it is
>> that is the difference between, for example, the objects int(3) and
>> int(4).  While your definition seems to be saying something similar it
>> does not seem very precise.
>
> I think necessarily so, or rather, it can only be specific for each
> class.  In the formulation: an object has identify, class, and value,
> class and value are separated.  Others have said that type/class is a
> universe of possible values and operations on those values.  Each
> instance has a particular value. 'Universe of possible values' is vague
> until one gets specific.  For some classes, the possible values are
> rather complex.

I prefer another definition of object: an object *is* a value, rather 
than *has* a value. That value consists of identity, type (or class), and 
everything else of interest which is sometimes also called "value". Since 
identity is usually unimportant, and type is assumed from context, we can 
often get away with stating that the "everything else of interest" is 
*the* value.

I usually talk about one of the three levels of value:

(1) The value of the NAME (or variable) x is the object int(3); that is, 
the thing denoted by the symbol x is the object int(3).


(2) The value of the OBJECT int(3) is the specific concrete instantiation 
that makes it the thing that it is rather than another thing (a 
complicated way of saying that the value of an object is itself); that 
is, the thing denoted by the symbol int(3) is some specific byte pattern 
in memory which causes that object to be int(3) rather than some other 
object.

To put it another way, the value of that object is whatever properties of 
the object distinguish it from any other the whole number 1. Since 
identity is (usually) unimportant for distinguishing one object from 
another (we usually care whether x==y, not whether x is y) the identity 
is not part of the value. We're generally indifferent to the serial 
number on our ten dollar bills: any note is (usually) as good as any 
other note. But sometimes identity is important, and in some specific 
contexts I'd be happy to say that the value of a symbol must include the 
identity of the object.


(3) But at another level, the value of the object int(3) is the abstract 
integer three. This is the only level at which I'm happy to talk about 
objects (as opposed to names) "having" a value: "object int(3) has the 
value three".


 
>> How would I use your definition to answer the following questions?
>> 
>> * How does an object get a value?
> 
> A Python interpreter, human or electronic, creates objects with values
> as directed by Python code.  How it does so is its private secret ;-).
> The directive code includes literals, expressions, and some statements.

I would answer that the object *is* the value, but with the proviso that 
we usually don't care about identity:

>>> x = 19990
>>> y = 19990
>>> x == y
True
>>> x is y
False

I'm happy to say that the value of x and the value of y are the same, 
even though they have different identities. But context is important: 
there are times were I would want to wrap identity under the umbrella of 
value. See below.

 
>> * 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
> Yes: mpz(3) where mpz is multi-precision int class with same set of
> possible values as Python ints.
> 
> ??? 3.0
> ??? Fraction(3,1)
> 
> While Python sees these as *equal*, one could say they are not the same
> because they indicate members of different (non-isomorphic) universes.

Whether we wish to say that mpz(3) has the same value as int(3) depends 
on what we care about, and we only care about that because our data types 
are leaky abstractions. In principle, we should be indifferent to whether 
x is int(3), float(3.0), mpz(3), or any other instantiation of the 
abstract numeral three. In practice, we're not indifferent: we prefer 
ints for mpz objects for some purposes, but not for others. If we care 
about the specifics, then we might say they have different values 
(becaus

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

[Terry Reedy]

[EMAIL PROTECTED] wrote:

On Nov 13, 4:53 pm, Terry Reedy wrote:

[EMAIL PROTECTED] wrote:


I have yet to see any reasonable definition of a Python
value in the Python docs or elsewhere, despite the fact
that a value is one of the three defining characteristics
of an object, a central concept in Python.

I noticed too.  My try:

The value of an object is the information that the object represents (or
that is stored with the object) that the interpreter uses to compute the
value of a new object when you use the object in an expression.  For
number objects, the number value.  For collection objects, the objects
collected. For functions, the signature and function performed when called.

How is that?


I am starting with the idea that "value" is what we call
whatever it is that is the difference between, for example,
the objects int(3) and int(4).  While your definition
seems to be saying something similar it does not seem
very precise.


I think necessarily so, or rather, it can only be specific for each 
class.  In the formulation: an object has identify, class, and value, 
class and value are separated.  Others have said that type/class is a 
universe of possible values and operations on those values.  Each 
instance has a particular value. 'Universe of possible values' is vague 
until one gets specific.  For some classes, the possible values are 
rather complex.



How would I use your definition to answer the following
questions?

* How does an object get a value?


A Python interpreter, human or electronic, creates objects with values 
as directed by Python code.  How it does so is its private secret ;-). 
The directive code includes literals, expressions, and some statements.



* 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
Yes: mpz(3) where mpz is multi-precision int class with same set of 
possible values as Python ints.


??? 3.0
??? Fraction(3,1)

While Python sees these as *equal*, one could say they are not the same 
because they indicate members of different (non-isomorphic) universes.



* Do all objects have values? (Ignore the Python
 docs if necessary.)


If one allows null values, I am current thinking yes.
Still, numbers, characters, and collections thereof of what code is 
usually about.



* What is the value of object()?


Essentially none, other than bool(object()) == True.
Ditto for None, other than bool(None) == False.
Otherwise, None and object convey no information.


* 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.  In those cases in which the class 
of an object can be and is changed to another class, the interpretation 
of the value/info of the instance could change and one might claim that 
the effective value and hence the value of the object has changed and 
hence the answer could be Yes.  But this is extremely rarely done and I 
could claim that this is a shortcut for creating a new object and 
deleting the old.



* If two objects have different unrelated types
 (i.e. not subclassed), are their values necessarily
 different (regardless of how they print, or act
 when used in an expression)?


No.  See above Q. about int(3).


* What if they aren't unrelated but one is a sub-
 class of the other?


Easier no than above.


* Can one completely hide an object's value by
 overriding methods?


You tell me ;-)
Do you have an example that you were thinking of?


* Can two objects have the same value, even if the
 methods of one have been overridden to hide it's
 value as completely as possible?

I wonder if all values come, directly or indirectly,
from "valued objects" created in the C-API?


CPython creates objects with values in C functions.  I presume most are 
exposed in the API.  But my definition is intentionally not specific to 
any implementation.



Or perhaps value is some sort of useful but fundamentally
undefinable concept


Either yes or defined in terms of information or universes.


that disappears when looked at too closely


No.


Leaving behind only state and behavior?


State is a choice amoung possible states, which is to say, information.
Behavior is determined by class,

Terry Jan Reedy

--
http://mail.python.org/mailman/listinfo/python-list

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

[rurpy]

On Nov 13, 4:53 pm, Terry Reedy wrote:
> [EMAIL PROTECTED] wrote:
>
>> I have yet to see any reasonable definition of a Python
>> value in the Python docs or elsewhere, despite the fact
>> that a value is one of the three defining characteristics
>> of an object, a central concept in Python.
>
> I noticed too.  My try:
>
> The value of an object is the information that the object represents (or
> that is stored with the object) that the interpreter uses to compute the
> value of a new object when you use the object in an expression.  For
> number objects, the number value.  For collection objects, the objects
> collected. For functions, the signature and function performed when called.
>
> How is that?

I am starting with the idea that "value" is what we call
whatever it is that is the difference between, for example,
the objects int(3) and int(4).  While your definition
seems to be saying something similar it does not seem
very precise.

How would I use your definition to answer the following
questions?

* How does an object get a value?

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

* Do all objects have values? (Ignore the Python
 docs if necessary.)

* What is the value of object()?

* Does an object's behavior (methods) affect
 its value?

* If two objects have different unrelated types
 (i.e. not subclassed), are their values necessarily
 different (regardless of how they print, or act
 when used in an expression)?

* What if they aren't unrelated but one is a sub-
 class of the other?

* Can one completely hide an object's value by
 overriding methods?

* Can two objects have the same value, even if the
 methods of one have been overridden to hide it's
 value as completely as possible?

I wonder if all values come, directly or indirectly,
from "valued objects" created in the C-API?
Or perhaps value is some sort of useful but fundamentally
undefinable concept that disappears when looked at too
closely, leaving behind only state and behavior?
--
http://mail.python.org/mailman/listinfo/python-list

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

[Terry Reedy]

[EMAIL PROTECTED] wrote:


I have yet to see any reasonable definition of a Python
value in the Python docs or elsewhere, despite the fact
that a value is one of the three defining characteristics
of an object, a central concept in Python.


I noticed too.  My try:

The value of an object is the information that the object represents (or 
that is stored with the object) that the interpreter uses to compute the 
value of a new object when you use the object in an expression.  For 
number objects, the number value.  For collection objects, the objects 
collected. For functions, the signature and function performed when called.


How is that?

Terry Jan Reedy

--
http://mail.python.org/mailman/listinfo/python-list

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

[rurpy]

On Nov 12, 7:09 pm, George Sakkis <[EMAIL PROTECTED]> wrote:
> On Nov 12, 4:05 pm, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>
>> greg wrote:
>> >> It's not only misleading, it's also a seriously flawed reading of the
>> >> original text - the Algol 60 report explicitly talks about assignment
>> >> of *values*.
>>
>> > Do you agree that an expression in Python has a value?
>>
>> > Do you agree that it makes sense to talk about assigning
>> > that value to something?
>>
>> Python's definition of the word "value" can be found in the language
>> reference:
>>
>> http://docs.python.org/reference/datamodel.html#objects-values-and-types
>
> Quoting the relevant part:
>
> "The value of some objects can change. Objects whose value can change
> are said to be mutable; objects whose value is unchangeable once they
> are created are called immutable."
>
> Strictly speaking that's not a definition; it doesn't say what a value
> is, only how it relates to objects. But regardless, according to this,
> a Python value is what the rest of the world usually calls "state",
...snip...

That just pushes the question to, "what's state?" doesn't it?
Is a method part of an object's state (and hence "value"?)
Are an object's data attribute values part of it's state?

Are the values of a, b, and c different below?

  a = int(1)
  class myint(int): pass
  b = myint(1)
  c = myint(1)
  c.foo = 2

I have yet to see any reasonable definition of a Python
value in the Python docs or elsewhere, despite the fact
that a value is one of the three defining characteristics
of an object, a central concept in Python.
--
http://mail.python.org/mailman/listinfo/python-list

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

[Terry Reedy]

Fredrik Lundh wrote:

greg wrote:


If you're going to indulge in argument by authority,
you need to pick authorities that can be considered,
er, authoritative in the field concerned...


Like Barbara Liskov, who's won tons of awards for her work on computer 
science and programming languages, and who was among the first to 
design, implement, and formally describe a language with *exactly* the 
same evaluation semantics as Python?  What did she and her co-authors 
have to say about the calling semantics in their new language?  Let's see:


"In particular it is not call by value because mutations
of arguments performed by the called routine will be
visible to the caller.  And it is not call by reference
because access is not given to the variables of the
caller, but merely to certain objects."


CLU reference manual. 1979  Google's searchable HTML version (apparently 
from OCR of scan package as .pdf) with a few mis-conversions.

http://64.233.169.104/search?q=cache:iNQhnst06X8J:www.oberon2005.ru/doc/doc-mit1979-000225e.pdf

We call the argument passing technique call by sharing, because the
argument objects are shared between the caller and the called routine.

She later. in 1992, called it "pass by object" (below).

But maybe they were just ignorant, and didn't really "get" how earlier 
languages worked?  Let's see what Liskov has to say about that:


"The group as a whole was quite knowledgeable about languages that
existed at the time. I had used Lisp extensively and had also
programmed in Fortran and Algol 60, Steve Zilles and Craig
Schaffert had worked on PL/I compilers, and Alan Snyder had done
extensive programming in C. In addition, we were familiar with
Algol 68, EL/1, Simula 67, Pascal, SETL, and various machine
languages. Early in the design process we did a study of other
languages to see whether we should use one of them as a basis for
our work [Aiello, 1974]. We ultimately decided that none would be
suitable as a basis. None of them supported data abstraction, and
we wanted to see where that idea would lead us without having to
worry about how it might interact with pre-existing
features. However, we did borrow from existing languages.  Our
semantic model is largely borrowed from Lisp; our syntax is
Algol-like."

Still think they didn't understand Algol's semantic model?


The second quote come from
A History of CLU, by Barbara Liskov 1992
http://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TR-561.pdf

Python owes more to CLU than I realized.

"Assignment has a type-independent meaning with the heap approach;
x := e
causes x to refer to the object obtained by evaluating expression e."

"arguments are passed "by object"; the (pointer to the) object resulting
from evaluating the actual argument expression is assigned to the 
formal. (Thus passing a parameter is just doing an assignment to the 
formal.)"


Exactly described Python also.

"we wanted to treat built-in and user-defined types alike"

Achieved fully in 3.0.  She notes a difference though: some built-in 
types have literals.  No user types do.


"We allow common operator symbols but these are only short forms for 
what is really happening, namely a call on an operation using its full 
t$o name. When the compiler encounters such a symbol, it "desugars" it 
by following a simple rule: it produces t$o where t is the type of the 
first argument, and o is the operation name associated with the symbol. 
Thus "x + y" is desugared to "t$add(x, y)" where t is the type of x."


In CLU and Python, methods belong to the class/type rather than to the 
instances (as in C++ she claims).


"""Not only is this approach simple and easy to understand, it applies 
to both built-in and user-defined types uniformly. To allow sugars to be 
used with a new type, the type definer need only choose the right
names for the operations. For example, to allow the use of +, he or she 
names the addition operation "add." """


Also, CLU has exceptions that terminate and iterators used in for 
statements.


Terry Jan Reedy

--
http://mail.python.org/mailman/listinfo/python-list

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

[Grant Edwards]

On 2008-11-13, greg <[EMAIL PROTECTED]> wrote:
> Grant Edwards wrote:
>
>> I stopped paying much attention to this thread a while ago, but
>> you've got to admire the persistence of somebody who soldiers
>> on even though Aahz, Fredrik Lund, and Steve Holden are all on
>> the other side of the argument...
>
> Those people clearly know a great deal about Python, and I
> respect them for that. However, that doesn't necessarily make
> them authorities on programming language terminology.
>
> If you're going to indulge in argument by authority, you need
> to pick authorities that can be considered, er, authoritative
> in the field concerned...

Based on past writings of all three, I've come to the
conclusion that (unlike some people I've met over the years)
they can be trusted to know (and not exceed) the limits of
their own knowledge and expertise.  IOW, they know what they
don't know.  So when they make a statement I give it
considerably more weight than I would most people.  There are
certainly areas in which they aren't authorities, but you
don't catch them making statements in those areas as if they
were.

There are other people I know who are probably just as
intelligent and just as expert (in other fields), but when they
get to the edge of what they know, they don't stop talking.
They either don't know (or won't admit) what they don't know.
AFAICT, they apparently just make up stuff in order to have
answers to questions.  Does that make sense?

All that aside, I don't know that I could win an argument with
them even if I was right and they were wrong.  ;)

-- 
Grant Edwards   grante Yow! I'm shaving!!
  at   I'M SHAVING!!
   visi.com
--
http://mail.python.org/mailman/listinfo/python-list

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

[rurpy]

On Nov 12, 2:05 pm, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Python's definition of the word "value" can be found in the language
> reference:
>
> http://docs.python.org/reference/datamodel.html#objects-values-and-types
>
> Using that definition, a Python expression yields an object, not an
> object value.

There is no definition of value there, just an assertion that values
exist.
--
http://mail.python.org/mailman/listinfo/python-list

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

[Fredrik Lundh]

greg wrote:


If you're going to indulge in argument by authority,
you need to pick authorities that can be considered,
er, authoritative in the field concerned...


Like Barbara Liskov, who's won tons of awards for her work on computer 
science and programming languages, and who was among the first to 
design, implement, and formally describe a language with *exactly* the 
same evaluation semantics as Python?  What did she and her co-authors 
have to say about the calling semantics in their new language?  Let's see:


"In particular it is not call by value because mutations
of arguments performed by the called routine will be
visible to the caller.  And it is not call by reference
because access is not given to the variables of the
caller, but merely to certain objects."

Let's take that again, with emphasis:

"IN PARTICULAR IT IS NOT CALL BY VALUE because mutations
of arguments performed by the called routine will be visible to
the caller. And IT IS NOT CALL BY REFERENCE because access
is not given to the variables of the caller, but merely to
certain objects."

"It is not".  "And it is not".

But maybe they were just ignorant, and didn't really "get" how earlier 
languages worked?  Let's see what Liskov has to say about that:


"The group as a whole was quite knowledgeable about languages that
existed at the time. I had used Lisp extensively and had also
programmed in Fortran and Algol 60, Steve Zilles and Craig
Schaffert had worked on PL/I compilers, and Alan Snyder had done
extensive programming in C. In addition, we were familiar with
Algol 68, EL/1, Simula 67, Pascal, SETL, and various machine
languages. Early in the design process we did a study of other
languages to see whether we should use one of them as a basis for
our work [Aiello, 1974]. We ultimately decided that none would be
suitable as a basis. None of them supported data abstraction, and
we wanted to see where that idea would lead us without having to
worry about how it might interact with pre-existing
features. However, we did borrow from existing languages.  Our
semantic model is largely borrowed from Lisp; our syntax is
Algol-like."

Still think they didn't understand Algol's semantic model?

:::

But nevermind - the real WTF with threads like this one is the whole 
idea that there are two and only two evaluation strategies to choose 
from.  That's a remarkable narrow-mindedness.




--
http://mail.python.org/mailman/listinfo/python-list

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

[greg]

Fredrik Lundh wrote:

Python's definition of the word "value" can be found in the language 
reference:


http://docs.python.org/reference/datamodel.html#objects-values-and-types


That whole passage is talking almost
exclusively about the value of an *object*:

  Every object has an identity, a type and a value...
  ...possible values for objects of that type...
  The value of some objects can change...

etc. etc. But we don't want to know about the value of
an object, we want to know about the value of an
*expression*. That section doesn't tell us. Nor does
it tell us that expressions don't *have* values. It
says nothing about expressions at all.

> Using that definition, a Python expression yields an object, not an
> object value.

And as I've said before, that's a perfectly fine viewpoint.
Because,

  An assignment statement evaluates the expression list (remember that this can
  be a single expression or a comma-separated list, the latter yielding a tuple)
  and assigns the single resulting object to each of the target lists, from left
  to right.

[http://docs.python.org/reference/simple_stmts.html#grammar-token-assignment_stmt]

and what it says about binding makes it clear that assignment
is a form of binding operation.

So it doesn't matter *what* you call the result of an expression
-- a value, an object, an object reference, or whatever -- the
differences all cancel out when you define assignment in a
corresponding way.

--
Greg
--
http://mail.python.org/mailman/listinfo/python-list

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

[Aaron Brady]

On Nov 13, 3:44 am, greg <[EMAIL PROTECTED]> wrote:
> Grant Edwards wrote:
> > I stopped paying much attention to this thread a while ago, but
> > you've got to admire the persistence of somebody who soldiers
> > on even though Aahz, Fredrik Lund, and Steve Holden are all on
> > the other side of the argument...
>
> Those people clearly know a great deal about Python,
> and I respect them for that. However, that doesn't
> necessarily make them authorities on programming
> language terminology.
>
> If you're going to indulge in argument by authority,
> you need to pick authorities that can be considered,
> er, authoritative in the field concerned...

The authors of C# and Java can be considered authorities in the field
concerned.  So authoritative, that if they want to redefine existing
terms, the masses must follow.
--
http://mail.python.org/mailman/listinfo/python-list

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

[greg]

Grant Edwards wrote:


I stopped paying much attention to this thread a while ago, but
you've got to admire the persistence of somebody who soldiers
on even though Aahz, Fredrik Lund, and Steve Holden are all on
the other side of the argument...


Those people clearly know a great deal about Python,
and I respect them for that. However, that doesn't
necessarily make them authorities on programming
language terminology.

If you're going to indulge in argument by authority,
you need to pick authorities that can be considered,
er, authoritative in the field concerned...

--
Greg
--
http://mail.python.org/mailman/listinfo/python-list

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

[greg]

Steve Holden wrote:

greg wrote:


Do you agree that it makes sense to talk about assigning
that value to something?


No. Why do you think that we are (mostly) careful to talk about binding
names and values instead?


That's an odd position to take, considering that the
Python docs use the word "assignment" all over the
place, and the language even has a statement known
as an "assignment statement".

The Python Language Reference has this to say about
assignment:

 The following constructs bind names: formal parameters to functions, import
 statements, class and function definitions (these bind the class or function
 name in the defining block), and targets that are identifiers if occurring in
 an assignment...
 [http://docs.python.org/reference/executionmodel.html]

What this suggests to me is that the reason the
Language Ref talks about binding is not because there's
anything wrong with the word assignment, but because
binding is a more general term. Assignment is one way
to perform binding, but there are other things that
perform binding as well.


But then various participants in this thread have
demonstrated an apparently infinite capacity to split hairs with the
presumed intention of proving themselves right and others wrong.


For my part, I'm not trying to "prove myself right",
I'm trying to be helpful by clearing up what seems to
me to be a misunderstanding about what the term
call-by-value implies. But it appears that some people
stubbornly refuse to have their misunderstandings
cleared up. :-)

That's how it looks from my end, anyway. No doubt from
the other end it looks like I'm the one being stubborn.
That's why I've been trying to inject some objectivity
by doing some research and finding authoritative
references to back up what I'm saying.

I'm learning things from all this, too. For example,
until recently I couldn't be sure I wasn't the only
person in the world who had thought of the idea of
defining call-by-value in terms of assignment rather
than copying. Turns out I'm not -- Backus et al, no
less, had exactly the same idea. And it seems they're
not the only ones, either -- more on that later.

--
Greg
--
http://mail.python.org/mailman/listinfo/python-list

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

[George Sakkis]

On Nov 12, 4:05 pm, Fredrik Lundh <[EMAIL PROTECTED]> wrote:

> greg wrote:
> >> It's not only misleading, it's also a seriously flawed reading of the
> >> original text - the Algol 60 report explicitly talks about assignment
> >> of *values*.
>
> > Do you agree that an expression in Python has a value?
>
> > Do you agree that it makes sense to talk about assigning
> > that value to something?
>
> Python's definition of the word "value" can be found in the language
> reference:
>
> http://docs.python.org/reference/datamodel.html#objects-values-and-types

Quoting the relevant part:

"The value of some objects can change. Objects whose value can change
are said to be mutable; objects whose value is unchangeable once they
are created are called immutable."

Strictly speaking that's not a definition; it doesn't say what a value
is, only how it relates to objects. But regardless, according to this,
a Python value is what the rest of the world usually calls "state",
while a value in a non-Python context is usually a synonym of
"object" (in the general sense, e.g. for Java including both
primitives and object references), i.e. there's the following
approximate mapping in terminology:

Python jargon  Non-python jargon
===
object value (primitive or composite)
value  state (set of an object's attribute bindings)

Thus both call-by-value and call-by-object can be correct
descriptions, depending on who you ask.

George
--
http://mail.python.org/mailman/listinfo/python-list

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

[Aahz]

In article <[EMAIL PROTECTED]>,
Grant Edwards  <[EMAIL PROTECTED]> wrote:
>On 2008-11-12, Steve Holden <[EMAIL PROTECTED]> wrote:
>> greg wrote:
>
>I stopped paying much attention to this thread a while ago, but
>you've got to admire the persistence of somebody who soldiers
>on even though Aahz, Fredrik Lund, and Steve Holden are all on
>the other side of the argument...

QOTW!  ;-)
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

"It is easier to optimize correct code than to correct optimized code."
--Bill Harlan
--
http://mail.python.org/mailman/listinfo/python-list

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

[Fredrik Lundh]

greg wrote:

It's not only misleading, it's also a seriously flawed reading of the 
original text - the Algol 60 report explicitly talks about assignment 
of *values*.


Do you agree that an expression in Python has a value?

>

Do you agree that it makes sense to talk about assigning
that value to something?


Python's definition of the word "value" can be found in the language 
reference:


http://docs.python.org/reference/datamodel.html#objects-values-and-types

Using that definition, a Python expression yields an object, not an 
object value.


For comparison, here's Algol's definition of the word "value":

"A value is an ordered set of numbers (special case: a single number), 
an ordered set of logical values (special case: a single logical value), 
or a label."


It should be obvious to anyone that Python is not Algol.

> If so, what is there to stop us from applying the Algol
> definition to Python?

The fact that we're talking about Python.  Python is not Algol.



--
http://mail.python.org/mailman/listinfo/python-list

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

[Grant Edwards]

On 2008-11-12, Steve Holden <[EMAIL PROTECTED]> wrote:
> greg wrote:

I stopped paying much attention to this thread a while ago, but
you've got to admire the persistence of somebody who soldiers
on even though Aahz, Fredrik Lund, and Steve Holden are all on
the other side of the argument...

-- 
Grant Edwards   grante Yow! Look DEEP into the
  at   OPENINGS!!  Do you see any
   visi.comELVES or EDSELS ... or a
   HIGHBALL?? ...
--
http://mail.python.org/mailman/listinfo/python-list

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

[Francesco Guerrieri]

On Wed, Nov 12, 2008 at 2:01 PM, Steve Holden <[EMAIL PROTECTED]> wrote:
> Now, can we get on to something substantive like how many angels can
> dance on the head of a pin?
>

Oh, come on, that's too easy! 42.
I thought that by now everybody knew that.

Francesco
--
http://mail.python.org/mailman/listinfo/python-list

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

[Steve Holden]

greg wrote:
> Fredrik Lundh wrote:
> 
>> It's not only misleading, it's also a seriously flawed reading of the
>> original text - the Algol 60 report explicitly talks about assignment
>> of *values*.
> 
> Do you agree that an expression in Python has a value?
> 
Most expressions have values. The ones whose evaluations don't raise
exceptions.

> Do you agree that it makes sense to talk about assigning
> that value to something?
> 
No. Why do you think that we are (mostly) careful to talk about binding
names and values instead?

> If so, what is there to stop us from applying the Algol
> definition to Python?
> 
Apparently nothing. But then various participants in this thread have
demonstrated an apparently infinite capacity to split hairs with the
presumed intention of proving themselves right and others wrong. By now
you are arguing at the level of whether turquoise can be called blue.
Frankly, my dear, I don't give a damn.

Now, can we get on to something substantive like how many angels can
dance on the head of a pin?

regards
 Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/

--
http://mail.python.org/mailman/listinfo/python-list

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

[greg]

Fredrik Lundh wrote:

It's not only misleading, it's also a seriously flawed reading of the 
original text - the Algol 60 report explicitly talks about assignment of 
*values*.


Do you agree that an expression in Python has a value?

Do you agree that it makes sense to talk about assigning
that value to something?

If so, what is there to stop us from applying the Algol
definition to Python?

--
Greg
--
http://mail.python.org/mailman/listinfo/python-list

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

[greg]

Steven D'Aprano wrote:

If you insist that Python is call by value, the only way that can work is 
by defining values to be references, which is nothing like Algol.


No, that's not the only way. You can also make it work
by accepting the original definition of call-by-value
at face value -- i.e. as equivalent to assignment,
without any implication of copying beyond what
assignment itself implies.

--
Greg
--
http://mail.python.org/mailman/listinfo/python-list

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

[greg]

Steven D'Aprano wrote:

Why should anyone take the "Revised Report on the Algorithmic Language 
Algol 60" as the "official" (only?) definition of call-by-value for all 
languages everywhere?


Since the term was more or less invented by the people
who designed Algol, I thought it would be a good idea to
find out, from as close to the source as possible, what
*they* intended it to mean.

Particularly since in practice, people's *understanding* of such terms 
have more to do with common practice than formal definitions.


If "common practice" includes languages such as Java,
VB and RealBasic, then it accords with the original
definition, as far as I can see.


I notice that you deleted the last sentence of the definition. I quote:

"As a consequence, variables called by value are to be considered as 
nonlocal to the body of the procedure, but local to the fictitious block 
(cf. section 5.4.3)."


I didn't include that because it's not really relevant --
it's an artifact of the way they describe the effect of a
procedure call by conceptually substituting the call with
the text of the called procedure. You can equally well
think of the parameters as being in the same scope as the
rest of the procedure's locals.


What are the consequences of such assignment?


It doesn't matter what assignment means in Algol, because
we're talking about Python. We already agree on what assignment
means in Python -- or at least I hope we do!

--
Greg

--
http://mail.python.org/mailman/listinfo/python-list

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

[Fredrik Lundh]

Aahz wrote:


There you have it -- call by value is offially defined in
terms of assignment. There is no mention in there of copying.

So it's perfectly correct to use it in relation to Python.


Except, of course, for the fact that it is generally misleading.


It's not only misleading, it's also a seriously flawed reading of the 
original text - the Algol 60 report explicitly talks about assignment of 
*values*.


I'm not aware of any language where a reference to an object, rather 
than the *contents* of the object, is seen as the object's actual value. 
 It's definitely not true for Python, at least.




--
http://mail.python.org/mailman/listinfo/python-list

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

[Arnaud Delobelle]

Steven D'Aprano <[EMAIL PROTECTED]> writes:

> I am very happy to say that x=1 implies that the value of x is the object 
> 1 itself, in fact I would insist on such a definition of value.
>
> If you insist that Python is call by value, the only way that can work is 
> by defining values to be references

That's a neat and concise way of summarising this whole thread.

-- 
Arnaud
--
http://mail.python.org/mailman/listinfo/python-list

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

[Steven D'Aprano]

On Wed, 12 Nov 2008 02:44:42 +, Steven D'Aprano wrote:

> But one thing is clear: values aren't references. Given the assignment
> x=1, the value of x is not "a reference to 1" but 1 itself. So the one
> thing we can unambiguously say is that Algol's assignment model is not
> the same as Python's assignment model.

Sorry, this is very misleading.

What I meant to say is that if you are one of those people who insist 
that values in Python are references, then Algol's assignment model is 
not that same as what you understand Python assignment to be.

I am very happy to say that x=1 implies that the value of x is the object 
1 itself, in fact I would insist on such a definition of value.

If you insist that Python is call by value, the only way that can work is 
by defining values to be references, which is nothing like Algol.



-- 
Steven
--
http://mail.python.org/mailman/listinfo/python-list

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

[Steven D'Aprano]

On Wed, 12 Nov 2008 13:10:10 +1300, greg wrote:

> Here is the definition of call-by-value from the "Revised Report on the
> Algorithmic Language Algol 60"
> :


Why should anyone take the "Revised Report on the Algorithmic Language 
Algol 60" as the "official" (only?) definition of call-by-value for all 
languages everywhere?

Particularly since in practice, people's *understanding* of such terms 
have more to do with common practice than formal definitions. You're 
welcome to tell people that tomatoes are actually berries from the Deadly 
Nightshade family of plants, rather than vegetables, but if you do so you 
better follow it up with further explanations.



> 4.7.3.1. Value assignment (call by value). All formal parameters quoted
> in the value part of the procedure declaration heading are assigned the
> values (cf. section 2.8. Values and types) of the corresponding actual
> parameters, these assignments being considers as being performed
> explicitly before entering the procedure body. The effect is as though
> an additional block embracing the procedure body were created in which
> these assignments were made to variables local to this fictitious block
> with types as given in the corresponding specifications (cf. section
> 5.4.5).

I notice that you deleted the last sentence of the definition. I quote:

"As a consequence, variables called by value are to be considered as 
nonlocal to the body of the procedure, but local to the fictitious block 
(cf. section 5.4.3)."

And what's the fictitious block? As I understand it, their intention is 
to say that calling a procedure foo(x) with an actual argument y should 
be considered the same as:

# start a new block (a new scope, in Python terminology)
x = y   # behave as if we explicitly assigned y to x
foo(x)  # enter the body of foo with argument x local to the new block


What are the consequences of such assignment? Unfortunately, assignment 
isn't unambiguously defined:


"4.2.3. Semantics. Assignment statements serve for assigning the value of 
an expression to one or several variables or procedure identifiers. 
Assignment to a procedure identifier may only occur within the body of a 
procedure defining the value of a function designator (cf. section 
5.4.4). The process will in the general case be understood to take place 
in three steps as follows:
4.2.3.1. Any subscript expression occurring in the left part variables 
are evaluated in sequence from left to right.
4.2.3.2. The expression of the statement is evaluated.
4.2.3.3. The value of the expression is assigned to all the left part 
variables, with any subscript expressions having values as evaluated in 
step 4.2.3.1."


In other words, assignment takes three steps: 

(1) evaluate the subscript expressions on the left part (presumably of 
the statement); 

(2) evaluate the expression of the statement (presumably the right hand 
side, but the document doesn't make that clear);

(3) assign the value of the expression.

Got that? Assignment means the value is assigned. Glad that's all clear 
then.

So given an assignment of x = y in Algol, it isn't clear from this 
document whether x and y refer to the same value, or if they merely have 
the same value by equality. That second case would imply copying. To put 
it in Python terms, following x = y we know that x == y is true but we 
don't know whether id(x) == id(y).


Can we at least determine what variables and values are? Well, almost... 

"3.1.3. Semantics. A variable is a designation given to a single value."

Okay, a variable is a designation (a name if you prefer) for a value. So 
what's a value?


"2.8. Values and types
 
A value is an ordered set of numbers (special case: a single number), an 
ordered set of logical values (special case: a single logical value), or 
a label.
Certain of the syntactic units are said to possess values. These values 
will in general change during the execution of the program The values of 
expressions and their constituents are defined in section 3. The value of 
an array identifier is the ordered set of values of the corresponding 
array of subscripted variables (cf. section 3.1.4.1)."


Now we're getting somewhere! Values are sets of numbers or sets of true/
false logical elements. Hmmm... apparently strings aren't values in 
Algol. Oh well.

But one thing is clear: values aren't references. Given the assignment 
x=1, the value of x is not "a reference to 1" but 1 itself. So the one 
thing we can unambiguously say is that Algol's assignment model is not 
the same as Python's assignment model.



-- 
Steven
--
http://mail.python.org/mailman/listinfo/python-list

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

[Aahz]

In article <[EMAIL PROTECTED]>,
greg  <[EMAIL PROTECTED]> wrote:
>
>Here is the definition of call-by-value from the
>"Revised Report on the Algorithmic Language Algol 60"
>:
>
>4.7.3.1. Value assignment (call by value). All formal parameters quoted in the 
>value part of the procedure declaration heading are assigned the values (cf. 
>section 2.8. Values and types) of the corresponding actual parameters, these 
>assignments being considers as being performed explicitly before entering the 
>procedure body. The effect is as though an additional block embracing the 
>procedure body were created in which these assignments were made to variables 
>local to this fictitious block with types as given in the corresponding 
>specifications (cf. section 5.4.5).
>
>There you have it -- call by value is offially defined in
>terms of assignment. There is no mention in there of copying.
>
>So it's perfectly correct to use it in relation to Python.

Except, of course, for the fact that it is generally misleading.
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

"It is easier to optimize correct code than to correct optimized code."
--Bill Harlan
--
http://mail.python.org/mailman/listinfo/python-list