On Friday, June 5, 2015 at 8:07:41 AM UTC+5:30, Steven D'Aprano wrote: > On Fri, 5 Jun 2015 08:59 am, random832 wrote: > > > On Thu, Jun 4, 2015, at 18:16, Steven D'Aprano wrote: > >> Remember, you've tried to claim that it is not invisible or unknown, so > >> you > >> must be able to see and know that value. So what is the value? > > > > It doesn't have to have a string representation to exist. But if you > > really want one? > > > >>>> object.__repr__(23) > > '<int object at 0x10024af00>' > > That's not a reference to the value. That's a string that describes the > object. If it returned > > "twenty-three" > > would you claim that the string "twenty three" is the value of x? > > I think there is a simple, obvious, common-sense answer here: > > * given `x = 23`, the value of x is 23; > > * given `x = [1, 2]`, the value of x is the given list [1, 2]; > > * given `x = "Hello World", the value of x is the string "Hello World"; > > * given `x = object()`, the value of x is the given instance of type object. > > That's so simple and obviously correct. Compare to: > > * given `x = 23`, the value of x is not actually 23, but some invisible > reference to 23; > > * given `x = [1, 2]`, the value of x is not actually [1, 2], but some > invisible reference to [1, 2]; > > etc. I'm sure you can extrapolate to the other examples. > > The *only* reason for making this claim is to rationalise the belief that > passing x to a function is pass by value. Since the list [1, 2] is > obviously not copied, it becomes necessary to find something, anything, > which *is* copied, and identify that as "the value of x". Is there any > other context where you would want to say that the value of x isn't [1, 2]? >
Sounds simple... Until you realize that what the *is* is emphasizing [your emphasis] is not all that clear. Consider the C canonical linked-list example (of some type T): struct node { T elem; struct node *next; }; Is the list in C to be identified with 'struct node'? If you will see the usage pattern you would find that in most cases the usage is for some p of type struct node* To make it more explicit there are TWO mutually recursive types: typedef struct node *nodeptr; struct node { T elem; nodeptr next; }; And now if we ask which of node and nodeptr should we identify with the list type, the answer is not quite clear. - In all cases of usage we would find we need to use nodeptr - Except for "newp = (nodeptr)malloc(sizeof(struct node))" - However nodeptr has no meaning other than referring (pointing) to something... What? My conclusion: C does not support lists at all in a first class way. The C programmer needs to visualize/imagine them in the nebulous gap between node and nodeptr. The same situation obtains here in python: The abstract platonic immutable list is non-existent in python Use no mutation and the pretence that the list [1,2] *is* the list [1,2] works. Start using mutation and the ground starts wobbling. The only way to stay steady (that I know) in this wobbly world is to hold to two concepts: 1. The abstract platonic immutable type -- good to think with, supported by python in only a half-assed way 2. The 'maybe-reference-maybe-value' actual mess And to keep dancing between these -- https://mail.python.org/mailman/listinfo/python-list