Re: why cannot assign to function call

Aahz wrote: In article , wrote: I think this is the key point. I am an experienced Python programmer, and I had to think long and hard about what you were saying, Mark, in order to understand how it applied to Python. I think this means that your model and/or your level of abstraction is not

Re: why cannot assign to function call

In article , wrote: > >I think this is the key point. I am an experienced Python programmer, >and I had to think long and hard about what you were saying, Mark, in >order to understand how it applied to Python. I think this means that >your model and/or your level of abstraction is not "natural

Re: why cannot assign to function call

Ethan Furman wrote: > >Specifically, how is a new name (pbr) different, in Python, from a new >name initialized as if by assignment (pbv)? It seems to me than you end >up with the same thing in either case (in Python, at least), making the >distinction non-existent. > >def func(bar): > bar

Re: why cannot assign to function call

Mark Wooding wrote: > Ethan Furman writes: > > > Mark Wooding wrote: > >> Here's what I think is the defining property of pass-by-value [...]: > >> > >> The callee's parameters are /new variables/, initialized /as if by > >> assignment/ from the values of caller's argument expressions. > >>

Re: why cannot assign to function call

Ethan Furman writes: > Mark Wooding wrote: >> Here's what I think is the defining property of pass-by-value [...]: >> >> The callee's parameters are /new variables/, initialized /as if by >> assignment/ from the values of caller's argument expressions. >> >> My soundbite definition for pass-b

Re: why cannot assign to function call

On Fri, 27 Feb 2009 23:55:43 -, Ethan Furman wrote: I'm not Mark, but you did post to the whole group! [snippety snip] Specifically, how is a new name (pbr) different, in Python, from a new name initialized as if by assignment (pbv)? It seems to me than you end up with the same thin

Re: why cannot assign to function call

Mark Wooding wrote: Steven D'Aprano wrote: > On the one hand, some people (me and possibly rurpy) consider "this is pass-by-foo" to be a statement about behaviour directly visible to the programmer. We have a set of behavioral traits in mind, and if a language exhibits those behaviours, then

Re: why cannot assign to function call

On Jan 5, 9:03 am, Derek Martin wrote: > On Sat, Jan 03, 2009 at 10:15:51AM +, Marc 'BlackJack' Rintsch wrote: > > On Fri, 02 Jan 2009 04:39:15 -0600, Derek Martin wrote: > > > > On Tue, Dec 30, 2008 at 02:21:29PM +, John O'Hagan wrote: > > > What the Python community often overlooks, when

Re: why cannot assign to function call

On Jan 14, 3:51 am, Mark Wooding wrote: > Aaron Brady wrote: > > On Jan 13, 5:06 pm, Mark Wooding wrote: > > snip > > > I'm going to move away from the formal semantics stuff and try a > > > different tack.  Here's what I think is the defining property of > > > pass-by-value (distilled from the

Re: why cannot assign to function call

Aaron Brady wrote: > On Jan 13, 5:06 pm, Mark Wooding wrote: > snip > > I'm going to move away from the formal semantics stuff and try a > > different tack. Here's what I think is the defining property of > > pass-by-value (distilled from the formal approach I described earlier, > > but shorn o

Re: why cannot assign to function call

Steven D'Aprano wrote: > > Ah! (say I) but assignment in C and Pascal looks different from the way > > it looks in C > > I'm sorry, that confuses me. Assignment in C looks different from the way > it looks in C? I guess the second C should be Python. Yes, you're right. Stupid mistake on my par

Re: why cannot assign to function call

On Tue, 13 Jan 2009 23:06:58 +, Mark Wooding wrote: > I'm going to move away from the formal semantics stuff and try a > different tack. Here's what I think is the defining property of > pass-by-value (distilled from the formal approach I described earlier, > but shorn of the symbolism): >

Re: why cannot assign to function call

On Jan 13, 5:06 pm, Mark Wooding wrote: snip > I'm going to move away from the formal semantics stuff and try a > different tack.  Here's what I think is the defining property of > pass-by-value (distilled from the formal approach I described earlier, > but shorn of the symbolism): > >   The calle

Re: why cannot assign to function call

Steven D'Aprano wrote: > I found it interesting. Well, that's something, at any rate. > I think this conversation is reaching it's natural end. Frustration > levels are rising. I think you may be right. That said... > So I'm going to take a different tack in an attempt to reduce > frustrat

Re: why cannot assign to function call

On Sat, 10 Jan 2009 15:46:35 +, Mark Wooding wrote: > [Another tome. I hope this contains sufficient new material to continue > to be of interest to other readers.] I found it interesting. I don't know about others. However, at 756 lines (including quoting) it was nearly double the size of

Re: why cannot assign to function call

ru...@yahoo.com wrote: > But if you'll note, I said "if ..." referring to a couple of > hypothetical C-like languages, so your chapter-and-verse quote from > the standard, while interesting and appreciated, was basically > irrelevant. Ah, what you actually said was still quoted above (thanks):

Re: why cannot assign to function call

Mark Wooding wrote: > ru...@yahoo.com wrote: >> Mark Wooding wrote: >> > ru...@yahoo.com wrote: >... >> > For another: >> > >> > static void bar(char v[]) { char ch = 0; v = &ch; } >> > /* type error if arrays truly passed by reference */ >> >> v can be used as an array reference, e.g. "v[1] =

Re: why cannot assign to function call

Steven D'Aprano wrote: > I guess this is where you explain again that arrays in C are "bizarre", > and that while "int arr[2]" inside a function body means "declare an > array of two ints and call it 'arr'", the exact same declaration in a > function parameter list means something else. I qu

Re: why cannot assign to function call

Aaron Brady wrote: > True or not, it requires the reader to know what references are. And, > since your definition conflicts with the C++ definition, it's not > clear that the requirement is good. I blame C++ for coopting a perfectly good word with a established well-understood meaning, and app

Re: why cannot assign to function call

On Sun, 11 Jan 2009 06:32:31 -0800, Paul Rubin wrote: > Steven D'Aprano writes: >> If it walks like pass-by-reference, and smells like pass-by-reference, >> and swims like pass-by-reference, is it still your contention that it >> is pass-by-value? > > Of course the C example is pass by value. I

Re: why cannot assign to function call

On Jan 11, 8:32 am, Paul Rubin wrote: > Steven D'Aprano writes: > > If it walks like pass-by-reference, and smells like pass-by-reference, > > and swims like pass-by-reference, is it still your contention that it is > > pass-by-value? > > Of course the C example is p

Re: why cannot assign to function call

Steven D'Aprano writes: > If it walks like pass-by-reference, and smells like pass-by-reference, > and swims like pass-by-reference, is it still your contention that it is > pass-by-value? Of course the C example is pass by value. It's just that the value being passed is an address. -- http://

Re: why cannot assign to function call

On Sun, 11 Jan 2009 03:25:24 +, Mark Wooding wrote: > Steven D'Aprano wrote: > >> I don't believe it is a red-herring. As I understand it, Mark and Joe >> insist that C is pass-by-value *even in the case of arrays*, despite >> the semantics of array passing being identical to the semantics o

Re: why cannot assign to function call

On Jan 10, 1:49 pm, Joe Strout wrote: > Aaron Brady wrote: > >> Aaron Brady wrote: > >>> Possible compromise.  You can think of functions as mutation-only. > >>> You pass the object, and it gets a new (additional) name.  The old > >>> name doesn't go in.   > >> That's correct.  The reference itsel

Re: why cannot assign to function call

ru...@yahoo.com wrote: > Mark Wooding wrote: > > ru...@yahoo.com wrote: > > > >> What is the observable difference between converting an > >> array to a reference (pointer) to that array and passing > >> the reference by value, and passing the array by reference? > > > > For one: > > > > #include

Re: why cannot assign to function call

Mark Wooding wrote: > ru...@yahoo.com wrote: > >> What is the observable difference between converting an >> array to a reference (pointer) to that array and passing >> the reference by value, and passing the array by reference? > > For one: > > #include > static size_t foo(char v[]) { return siz

Re: why cannot assign to function call

Steven D'Aprano wrote: > I don't believe it is a red-herring. As I understand it, Mark and Joe > insist that C is pass-by-value *even in the case of arrays*, despite the > semantics of array passing being identical to the semantics of pass-by- > reference in (say) Pascal. But they aren't. I'

Re: why cannot assign to function call

On Sun, 11 Jan 2009 01:22:48 +, Rhodri James wrote: > On Sat, 10 Jan 2009 18:44:37 -, wrote: > >> What is the observable difference between converting an array to a >> reference (pointer) to that array and passing the reference by value, >> and passing the array by reference? > > This i

Re: why cannot assign to function call

Steven D'Aprano wrote: > There are actually three fundamental characteristics of pass-by-reference: > > * passing a value by reference does not lead to the value being copied, > in contrast with pass-by-value where it does; > > * modifications to the value passed by reference are visible to th

Re: why cannot assign to function call

On Sat, 10 Jan 2009 18:44:37 -, wrote: What is the observable difference between converting an array to a reference (pointer) to that array and passing the reference by value, and passing the array by reference? This is a red herring, though. From either viewpoint, C arrays are anomalous

Re: why cannot assign to function call

On Sat, 10 Jan 2009 12:52:47 -0700, Joe Strout wrote: >> What is the observable difference between converting an array to a >> reference (pointer) to that array and passing the reference by value, >> and passing the array by reference? > > The difference is whether an assignment to the formal par

Re: why cannot assign to function call

Aaron Brady wrote: Aaron Brady wrote: Possible compromise. You can think of functions as mutation-only. You pass the object, and it gets a new (additional) name. The old name doesn't go in. That's correct. The reference itself is passed in, not the variable (or expression) that held or ge

Re: why cannot assign to function call

ru...@yahoo.com wrote: What is the observable difference between converting an array to a reference (pointer) to that array and passing the reference by value, and passing the array by reference? The difference is whether an assignment to the formal parameter (within the function) affects the

Re: why cannot assign to function call

ru...@yahoo.com wrote: > What is the observable difference between converting an > array to a reference (pointer) to that array and passing > the reference by value, and passing the array by reference? For one: #include static size_t foo(char v[]) { return sizeof v; } int main(void) { char

Re: why cannot assign to function call

On Jan 9, 6:47 am, Mark Wooding wrote: > ru...@yahoo.com wrote: > > As a side comment (because it always bugs me when I read this, even > > though I read it in very authoritative sources), ISTM that C passes > > everything by value except arrays; they are passed by reference (by > > passing a poi

Re: why cannot assign to function call

Aaron Brady wrote: > Lastly, I don't see any reason why we couldn't make both explanations > available. 'For those coming from Java/etc; for those coming from > C++/etc.' They would both get read. That's what I was just thinking .. there are lots of others, too: "for those coming from r

Re: why cannot assign to function call

ru...@yahoo.com wrote: > Agreed. I think the docs, especially those that develop > the conceptual model of how Python work at runtime, could > use some major attention. If we can achieve consensus in this (still remarkably civil) discussion, we might be able to amend the docs. > I would be wil

Re: why cannot assign to function call

[Another tome. I hope this contains sufficient new material to continue to be of interest to other readers.] Steven D'Aprano wrote: > On Fri, 09 Jan 2009 20:23:11 +, Mark Wooding wrote: > > > No: not directly. The Python program deals solely with references; > > anything involving actual ob

Re: why cannot assign to function call

On Jan 9, 9:30 am, Joe Strout wrote: > Aaron Brady wrote: > > Possible compromise.  You can think of functions as mutation-only. > > You pass the object, and it gets a new (additional) name.  The old > > name doesn't go in.   > > That's correct.  The reference itself is passed in, not the variable

Re: why cannot assign to function call

On Fri, 09 Jan 2009 20:23:11 +, Mark Wooding wrote: > Steven D'Aprano wrote: > >> I'm pretty sure that no other pure-Python coder has manipulated >> references either. They've manipulated objects. > > No: not directly. The Python program deals solely with references; > anything involving a

Re: why cannot assign to function call

Rhodri James wrote: > On Sat, 10 Jan 2009 00:21:27 -, wrote: >> IIRC, Someone posted here that his experience was >> that 12-year old kids (presumably without programming >> experience) had no problem with Python and references >> when described as "names given to an object". (From >> memory,

Re: why cannot assign to function call

Mark Wooding wrote: > ru...@yahoo.com wrote: > >> If one accepts that there are a "lot" of people who post in here that >> clearly are surprised by Python's assignment semantics, > > But one should not accept that. One might accept that there are many > who post who claim that they are surprised

Re: why cannot assign to function call

Steven D'Aprano wrote: > Er, perhaps you missed that I was replying to Joe Strout. Yes, evidently. My apologies for the mix up! -- [mdw], who obviously should put the keyboard down now. -- http://mail.python.org/mailman/listinfo/python-list

Re: why cannot assign to function call

Joe Strout wrote: > No, actually, that was me. rurpy's list was something like C, FORTRAN, > Perl, and VBA. My mistake -- I failed to read the quoting properly. Apologies to all. We still dealt with C. Fortran (to give it its modern spelling) has a similar data model to C, but passes argume

Re: why cannot assign to function call

On Sat, 10 Jan 2009 00:21:27 -, wrote: Joe Strout wrote: ru...@yahoo.com wrote: [snip] Pointers are passed and assigned by value, just as other types (disputedly except arrays) are. One can then use that pointer to manually effect pass-(the-value-pointed-to)-by-reference, or sharing, e

Re: why cannot assign to function call

On 2009-01-10, Joe Strout wrote: > Mark Wooding wrote: > >> As an aside, I don't notice anywhere near as much confusion in Lisp and >> Scheme groups, which might be surprising since Lisp and Scheme have >> precisely the same data model, argument passing convention, and >> assignment semantics, as

Re: why cannot assign to function call

On Fri, 09 Jan 2009 21:03:39 +, Mark Wooding wrote: > Steven D'Aprano wrote: > >> Python doesn't do the same thing as C. It actually passes the same >> value to the function, without copying it. >> >> Why oh why do you keep insisting that Python is no different from C? > > I'm beginning to

Re: why cannot assign to function call

On Fri, Jan 9, 2009 at 7:11 PM, Joe Strout wrote: > Mark Wooding wrote: > > > .NET isn't a language at all: >> rather, it's a virtual machine, runtime system, class library and family >> of languages each of which may have idiosyncratic semantics. >> > > But they don't, AFAIK -- they all have th

Re: why cannot assign to function call

Joe Strout wrote: > ru...@yahoo.com wrote: > >>> I never claimed that you *couldn't* have copy semantics in C; you can do >>> almost anything you want in C (or C++). But the *normal* usage of an >>> array is via a pointer, in which case the semantics are exactly the same >>> as in Python, Java, RE

Re: why cannot assign to function call

Mark Wooding wrote: As an aside, I don't notice anywhere near as much confusion in Lisp and Scheme groups, which might be surprising since Lisp and Scheme have precisely the same data model, argument passing convention, and assignment semantics, as Python has. Nor is there anywhere near as muc

Re: why cannot assign to function call

ru...@yahoo.com wrote: > If one accepts that there are a "lot" of people who post in here that > clearly are surprised by Python's assignment semantics, But one should not accept that. One might accept that there are many who post who claim that they are surprised by Python's assignment semant

Re: why cannot assign to function call

Steven D'Aprano wrote: > Python doesn't do the same thing as C. It actually passes the same value > to the function, without copying it. > > Why oh why do you keep insisting that Python is no different from C? I'm beginning to think that you're not bothing to read what I'm writing, but I'll as

Re: why cannot assign to function call

Aaron Brady wrote: > Possible compromise. You can think of functions as mutation-only. > You pass the object, and it gets a new (additional) name. The old > name doesn't go in. Huh? That doesn't explain circular data structures at all, unless your idea of `name' is unrelated to the identifi

Re: why cannot assign to function call

[Sigh. I must apologize for the length of this article. I can't, alas, see a satisfactory way of trimming it. The doubly-quoted stuff later on was by me.] Steven D'Aprano wrote: > I'm pretty sure that no other pure-Python coder has manipulated > references either. They've manipulated objects

Re: why cannot assign to function call

ru...@yahoo.com wrote: I never claimed that you *couldn't* have copy semantics in C; you can do almost anything you want in C (or C++). But the *normal* usage of an array is via a pointer, in which case the semantics are exactly the same as in Python, Java, REALbasic, .NET, etc. Arrays are th

Re: why cannot assign to function call

Joe Strout wrote: > ru...@yahoo.com wrote: > a = array (1,2,3) b = a a[1] = 4 print b C, C++, VBA, Fortran, Perl: 1, 2, 3 Python: 1, 4, 3 >>> You are mistaken >> >> I don't think so. >> See http://groups.google.com/group/comp.lang.python/msg/f99d5a0d8f86

Re: why cannot assign to function call

On Fri, 09 Jan 2009 08:30:46 -0700, Joe Strout wrote: > That's correct. The reference itself is passed in, not the variable (or > expression) that held or generated the reference in the calling code. > > This is no different from, in C, passing an integer: > > void foo(int bar) { > bar = 42

Re: why cannot assign to function call

Joe Strout wrote: > Aaron Brady wrote: > >> Possible compromise. You can think of functions as mutation-only. >> You pass the object, and it gets a new (additional) name. The old >> name doesn't go in. > > That's correct. The reference itself is passed in, not the variable (or > expression)

Re: why cannot assign to function call

ru...@yahoo.com wrote: > As a side comment (because it always bugs me when I read this, even > though I read it in very authoritative sources), ISTM that C passes > everything by value except arrays; they are passed by reference (by > passing a pointer to the array by value.) Admittedly, the clo

Re: why cannot assign to function call

Aaron Brady wrote: Possible compromise. You can think of functions as mutation-only. You pass the object, and it gets a new (additional) name. The old name doesn't go in. That's correct. The reference itself is passed in, not the variable (or expression) that held or generated the refere

Re: why cannot assign to function call

ru...@yahoo.com wrote: a = array (1,2,3) b = a a[1] = 4 print b C, C++, VBA, Fortran, Perl: 1, 2, 3 Python: 1, 4, 3 You are mistaken I don't think so. See http://groups.google.com/group/comp.lang.python/msg/f99d5a0d8f869b96 The code I quoted there was tested. In the C/C++ case, arr

Re: why cannot assign to function call

On Jan 9, 4:01 am, Steven D'Aprano wrote: > On Thu, 08 Jan 2009 18:33:50 +, Mark Wooding wrote: > > [Steven's message hasn't reached my server, so I'll reply to it here. > > Sorry if this is confusing.] > > > Aaron Brady wrote: > >> On Jan 8, 1:45 am, Steven D'Aprano > >> wrote: > >> > On We

Re: why cannot assign to function call

On Thu, 08 Jan 2009 18:33:50 +, Mark Wooding wrote: > [Steven's message hasn't reached my server, so I'll reply to it here. > Sorry if this is confusing.] > > Aaron Brady wrote: >> On Jan 8, 1:45 am, Steven D'Aprano >> wrote: >> > On Wed, 07 Jan 2009 10:17:55 +, Mark Wooding wrote: >> >

Re: why cannot assign to function call

Joe Strout wrote: > ru...@yahoo.com wrote: > >> "the same as anyone else's" only if [Python's] "idea >> of assignment" does not include producing the same >> results. >> >> a = array (1,2,3) >> b = a >> a[1] = 4 >> print b >> >> C, C++, VBA, Fortran, Perl: 1, 2, 3 >> Python: 1, 4, 3 > > Y

Re: why cannot assign to function call

ru...@yahoo.com wrote: "the same as anyone else's" only if [Python's] "idea of assignment" does not include producing the same results. a = array (1,2,3) b = a a[1] = 4 print b C, C++, VBA, Fortran, Perl: 1, 2, 3 Python: 1, 4, 3 You are mistaken (except perhaps in the Fortran case,

Re: why cannot assign to function call

Mark Wooding wrote: ... > I agree with the comment about Pascal, but C is actually pretty similar > to Python here. C only does pass-by-value. As a side comment (because it always bugs me when I read this, even though I read it in very authoritative sources), ISTM that C passes everything by valu

Re: why cannot assign to function call

Mark Wooding wrote: ... > Python doesn't need another name for assignment, OK. > because actually its > idea of assignment is the same as anyone else's. The difference is in > the way it deals with objects. See argument elsewhere. "the same as anyone else's" only if [Python's] "idea of assignm

Re: why cannot assign to function call

Mark Wooding wrote: The `they're just objects' model is very simple, but gets tied up in knots explaining things. The `it's all references' model is only a little more complicated, but explains everything. But it *over* explains, because it implies things that "everybody knows" about reference

Re: why cannot assign to function call

Erik Max Francis wrote: > Terry Reedy wrote: > > > >>> a='par'+'rot' > > >>> b='parrot' > > >>> a is b > > True > > One exactly doesn't really say much. It's implementation dependent, and > depends on the length of the string: > > >>> a = 'this is a much longer ' + 'parrot' > >>> b = 'thi

Re: why cannot assign to function call

[Steven's message hasn't reached my server, so I'll reply to it here. Sorry if this is confusing.] Aaron Brady wrote: > On Jan 8, 1:45 am, Steven D'Aprano > wrote: > > On Wed, 07 Jan 2009 10:17:55 +, Mark Wooding wrote: > > > > > The `they're just objects' model is very simple, but gets tied

Re: why cannot assign to function call

Absolutely. Trivially and at a high level, teaching python to kids who are learning programming as introductory material teaching python to motivated college graduate students teaching python to adult non-professional programmers with a need to learn python (like for instance, frustrated account

Re: why cannot assign to function call

Aaron Brady wrote: > On Jan 8, 1:45 am, Steven D'Aprano > wrote: >> On Wed, 07 Jan 2009 10:17:55 +, Mark Wooding wrote: > snip >>> The `they're just objects' model is very simple, but gets tied up in >>> knots explaining things. The `it's all references' model is only a >>> little more compli

Re: why cannot assign to function call

ru...@yahoo.com wrote: > I thought you were objecting to Python's use of the term "binding" > when you wrote: [snip] > in response to someone talking about "...all those who use the term > \"name binding\" instead of variable assignment...". Oh, that. Well, the terms are `binding' and `assign

Re: why cannot assign to function call

On Jan 8, 1:45 am, Steven D'Aprano wrote: > On Wed, 07 Jan 2009 10:17:55 +, Mark Wooding wrote: snip > > The `they're just objects' model is very simple, but gets tied up in > > knots explaining things.  The `it's all references' model is only a > > little more complicated, but explains everyt

Re: why cannot assign to function call

On Wed, 07 Jan 2009 03:45:00 -0800, sturlamolden wrote: > On Jan 7, 2:02 am, Steven D'Aprano > wrote: > >> In Python code, there are no references and no dereferencing. > > The why does CPython keep track of reference counts? Two different levels of explanation. At the level of Python code, yo

Re: why cannot assign to function call

On Wed, 07 Jan 2009 10:17:55 +, Mark Wooding wrote: > Steven D'Aprano wrote: > >> Only in the sense that the behaviour of *real world* objects don't >> entirely match the behaviour of Python objects. If you just accept that >> Python objects can be in two places at once, an unintuitive conce

Re: why cannot assign to function call

Rhodri James wrote: On Thu, 08 Jan 2009 00:45:06 -, wrote: When I started using Python I had no problem with Python's assignment semantics because I had been using references in Perl for years. I did not have a very hard time with Perl's references, after I recognized their similarities t

Re: why cannot assign to function call

On Thu, 08 Jan 2009 00:45:06 -, wrote: When I started using Python I had no problem with Python's assignment semantics because I had been using references in Perl for years. I did not have a very hard time with Perl's references, after I recognized their similarities to C's pointers. But

Re: why cannot assign to function call

On Wed, Jan 7, 2009 at 7:22 PM, Terry Reedy wrote: > Joe Strout wrote: > > That's not necessarily true. If you have >> >> a = "par" + "rot" >> b = "parrot" >> >> then, most likely (though it depends on how clever the compiler >> optimizations are), there are two different string objects conta

Re: why cannot assign to function call

Terry Reedy wrote: Joe Strout wrote: That's not necessarily true. If you have a = "par" + "rot" b = "parrot" then, most likely (though it depends on how clever the compiler optimizations are), there are two different string objects containing the data "parrot". >>> a='par'+'rot' >>

Re: why cannot assign to function call

On Jan 5, 12:21 pm, Derek Martin wrote: ... > I understand why the assignment model works the way it does, and it's > quite sensible, *when you understand it*. However, I do also think > that to someone who has not encountered such a model before, and who > has not had it explained to them, and/o

Re: why cannot assign to function call

Joe Strout wrote: That's not necessarily true. If you have a = "par" + "rot" b = "parrot" then, most likely (though it depends on how clever the compiler optimizations are), there are two different string objects containing the data "parrot". >>> a='par'+'rot' >>> b='parrot' >>> a is

Re: why cannot assign to function call

Dan Esch wrote: In essence, the implication of immutability for Python is that there is only one "parrot", one "spam,"in fact one anything. (This seems like it must hold for data primitives - does it hold for complex objects as well? It seems it must...) In addition there is only one 1, and on

Re: why cannot assign to function call

On Jan 6, 9:20 pm, Mark Wooding wrote: > ru...@yahoo.com wrote: > > Is not the proper term "aliasing"? Perhaps Python "variables" should > > be called "alises". > > No. The proper term is most definitely `binding': see SICP, for > example. (Wikipedia has a link to the full text.) I thought yo

Re: why cannot assign to function call

Okay, thanks... Still trying to wrap my fragile little VBA-corrupted brain around names, namespaces, and objects. Progress is being made. For me, the naive idea of variable ==> label for bin has been hard to get past simply because someone in the the back of my head is screaming, "Wait, if the

Re: why cannot assign to function call

Dan Esch wrote: > Wait a sec... > > I think I get this... > > In essence, the implication of immutability for Python is that there is > only one "parrot", one "spam,"in fact one anything. (This seems like it > must hold for data primitives - does it hold for complex objects as > well? It seems

Re: why cannot assign to function call

Wait a sec... I think I get this... In essence, the implication of immutability for Python is that there is only one "parrot", one "spam,"in fact one anything. (This seems like it must hold for data primitives - does it hold for complex objects as well? It seems it must...) In addition there is o

Re: why cannot assign to function call

On Wed, 07 Jan 2009 03:45:00 -0800, sturlamolden wrote: > On Jan 7, 2:02 am, Steven D'Aprano > wrote: > >> In Python code, there are no references and no dereferencing. > > The why does CPython keep track of reference counts? Show me the *Python* code that does that. Using reference counting

Re: why cannot assign to function call

On Jan 7, 2:02 am, Steven D'Aprano wrote: > In Python code, there are no references and no dereferencing. The why does CPython keep track of reference counts? > You can't, because Python doesn't have references. In a language with > references, that's easy. Python does not 'pass-by-reference'

Re: why cannot assign to function call

Steven D'Aprano wrote: > Only in the sense that the behaviour of *real world* objects don't > entirely match the behaviour of Python objects. If you just accept > that Python objects can be in two places at once, an unintuitive > concept I accept but hardly difficult to grasp, then you don't need

Re: why cannot assign to function call

On Wed, 07 Jan 2009 03:49:02 +, Mark Wooding wrote: > Steven D'Aprano wrote: > >> The only tricky thing is that items 1, 2 and 3 can be inside two >> different boxes at the same time. There's no obvious real world analogy >> to that without the boxes being nested. This ability for objects to

Re: why cannot assign to function call

"Mark Wooding" wrote: > A better analogy. The objects are scattered across the floor. No > object is contained in another. However, we have a plentiful supply of > bits of string, each of which is tied to a Teflon-covered paperweight at > one end and has a blob of Blu-Tack on the other. Inste

Re: why cannot assign to function call

Mark Wooding wrote: > Steven D'Aprano wrote: > >> The only tricky thing is that items 1, 2 and 3 can be inside two >> different boxes at the same time. There's no obvious real world analogy >> to that without the boxes being nested. This ability for objects to be in >> two places at once (or e

Re: why cannot assign to function call

ru...@yahoo.com wrote: > Is not the proper term "aliasing"? Perhaps Python "variables" should > be called "alises". No. The proper term is most definitely `binding': see SICP, for example. (Wikipedia has a link to the full text.) The topic of `aliasing' deals with a problem in compiler imple

Re: why cannot assign to function call

Steven D'Aprano wrote: > The only tricky thing is that items 1, 2 and 3 can be inside two > different boxes at the same time. There's no obvious real world analogy > to that without the boxes being nested. This ability for objects to be in > two places at once (or even to be inside themselves!

Re: why cannot assign to function call

Steven D'Aprano wrote: > If I wanted a reference to a list, I'd expect to *dereference* the > reference to get to the list. That's not what Python forces you do to: > you just use the list as the list object itself. That's odd. No, you give a reference to the list to a function, and the funct

Re: why cannot assign to function call

On Jan 6, 7:03 am, Mark Wooding wrote: ... > > It seems that you don't include in the Python community all those who > > use the term "name binding" instead of variable assignment > > specifically because it gives new users a clue that Python is not the > > same as C. > > Unfortunately, this pract

Re: why cannot assign to function call

On Tue, 06 Jan 2009 13:43:01 -0800, Aaron Brady wrote: > I think one of the ideas we have trouble communicating is that [1, 2, 3] > and [4, 5, 6] can be the same object Not at the same time they can't. > (using '[:]='), but [1, 2, 3] and [1, 2, 3] don't have to be. I don't think this is hard

Re: why cannot assign to function call

On Tue, 06 Jan 2009 14:32:04 +, Mark Wooding wrote: > Derek Martin wrote: > >> I think I have though, not that it matters, since that was never really >> my point. Python's assignment model requires more explanation than the >> traditional one, simply to state what it does. That alone is e

Re: why cannot assign to function call

On Tue, 06 Jan 2009 14:03:16 +, Mark Wooding wrote: >> You've also missed out on probably twenty years of CS where Java (using >> the same assignment model as Python!) has been *the* language of choice >> for undergrad CS, not to mention those introductory courses which use >> Python. > > The

  1   2   >