Re: Call by binding [was Re: [Tutor] beginning to code]
Rhodri James : > On 25/09/17 20:40, Marko Rauhamaa wrote: >> A pointer is something that points to a data object. > > In that case you are using "pointer" in such an informal sense that > making deductions from it is unlikely to be successful. Propose a name for the concept. Candidates so far: "pointer", "location", "address", "identity", "binding", "leash", "link". Unfortunately, "reference" is used for something else in the language spec. The word "address" is used by "An executable operational semantics for Python" http://gideon.smdng.nl/wp-content/uploads/thesis.pdf> This lengthy debate is exacerbated by the language spec pretending the concept doesn't exist and thus doesn't need a name. However, as is evident in the above master's thesis, you can't define Python's object model without it. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
On 25/09/17 21:00, Tim Golden wrote: (Slight sigh). Can I step in as a list owner and ask the people who are so very fond of debating this topic again and again: please let it drop. But, but... someone on the internet is wrong! https://www.facebook.com/playingrapunzel/videos/10153716804864491/ :-) -- Rhodri James *-* Kynesim Ltd -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
On 25/09/17 20:40, Marko Rauhamaa wrote: Rhodri James : On 25/09/17 15:26, Marko Rauhamaa wrote: That's not what I said. I said all expressions *evaluate to* pointers. This may well be true in particular implementations, but it is an implementation detail so Chris' point still stands. Another implementation could evaluate expressions to indices (as BCPL used to treat its globals), pieces of string or cheese, who knows? Those are all pointers. A pointer is something that points to a data object. In that case you are using "pointer" in such an informal sense that making deductions from it is unlikely to be successful. -- Rhodri James *-* Kynesim Ltd -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
Chris Angelico : > I've explained Python's (or JavaScript's, since they're the same) > object model to a number of novice programmers without any > difficulties, without talking about pointers or invisible values or > any of that junk. There are just two things to explain: the concept of > names referring to objects, and variable scope. The JavaScript spec wrt assignment etc is actually a bit difficult to understand: https://www.ecma-international.org/ecma-262/5.1/>. Scheme, which also shares the same object model with Python, has a very down-to-earth specification that uses the term "location:" http://schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-6.ht ml#%_sec_3.4> Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
On Tue, Sep 26, 2017 at 4:25 PM, Gregory Ewing wrote: > Neil Cerutti wrote: >> >> The quest to find a succinct way to categorize Python's argument >> passing for non-Python programmers strikes me as a sincere effort >> to to simplify something that just isn't simple. > > > I don't see how it's useful to do that in the first place. > Under what circumstances would you find yourself having to > explain *just* Python parameter passing and nothing else > about the language? And this entire debate is ONLY about trying to explain to people who already know some other language AND think that call-by-value and call-by-reference are the only two options. I've explained Python's (or JavaScript's, since they're the same) object model to a number of novice programmers without any difficulties, without talking about pointers or invisible values or any of that junk. There are just two things to explain: the concept of names referring to objects, and variable scope. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
Neil Cerutti wrote: The quest to find a succinct way to categorize Python's argument passing for non-Python programmers strikes me as a sincere effort to to simplify something that just isn't simple. I don't see how it's useful to do that in the first place. Under what circumstances would you find yourself having to explain *just* Python parameter passing and nothing else about the language? -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
Tim Golden wrote: On 25/09/2017 20:40, Marko Rauhamaa wrote: Rhodri James : On 25/09/17 15:26, Marko Rauhamaa wrote: That's not what I said. I said all expressions *evaluate to* pointers. This may well be true in particular implementations, but it is an implementation detail so Chris' point still stands. Another implementation could evaluate expressions to indices (as BCPL used to treat its globals), pieces of string or cheese, who knows? Those are all pointers. A pointer is something that points to a data object. (Slight sigh). Can I step in as a list owner and ask the people who are so very fond of debating this topic again and again: please let it drop. Threads such as this can remain interesting when the discussion generates a better understanding of the subject matter as the contributors are forced to articulate their positions leading to some kind of convergence of understanding. However, even if this were the only iteration of this debate, it would be clear by now that there's no chance of a simple "I see what you mean" moment. And this is far from the only iteration, even in the past few months. I feel for your need to demonstrate the validity of your respective positions. But it has moved on from being an enlightening debate and into the realms of mere tedium. Thanks. TJG Perhaps it would be better to amass examples and let them speak for themselves? -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
Chris Angelico wrote: On Tue, Sep 26, 2017 at 5:35 AM, Marko Rauhamaa wrote: Chris Angelico : On Tue, Sep 26, 2017 at 12:26 AM, Marko Rauhamaa wrote: Sorry, that was my bad in the terminology. But where do you get that all Python expressions evaluate to pointers? What do they evaluate to if not pointers? Anton's "identities" would work, too. "Address" would do, as well. I have previously proposed the term "leash." Call it "link" or "handle" or "arrow" if you want to. The term used isn't important. What's important is to understand that each expression and subexpression produces and operates on pointers. They evaluate to objects. Not to pointers to objects. Not to references to objects. To objects. Expressions evaluate to actual objects, and when you assign "name = value", you bind the name to the object that value evaluates to. ChrisA And when you pass a reference r to a function, a copy of the reference is passed. So even if you reassign *that* copy of r to refer to another object, upon return, r still still refers to whatever it did originally. ::: case closed :::, I think. -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
On 2017-09-25, Steve D'Aprano wrote: > So I believe that either "call by binding" or "call by > assignment" could both equally apply to any and all languages > with function parameters, regardless of implementation or the > language's defined semantics. I disagree on C++ where there's a keen difference between assignment and initialization, but I think I get what you mean, generally. If the objection is that "call by assignment" is just passing-the-buck, I won't argue with that. The quest to find a succinct way to categorize Python's argument passing for non-Python programmers strikes me as a sincere effort to to simplify something that just isn't simple. If calling it, "pass by assignment," is admitting defeat, then so be it. -- Neil Cerutti -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
Chris Angelico : > On Tue, Sep 26, 2017 at 5:36 AM, Marko Rauhamaa wrote: >> Chris Angelico : >>> You need *some* support for your assertion that there are pointers, >> >> What would convince you? > > Evidence, or a statement from the documentation. I mean, what piece of Python code could decide if I'm right or wrong? Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
On 25/09/2017 20:40, Marko Rauhamaa wrote: Rhodri James : On 25/09/17 15:26, Marko Rauhamaa wrote: That's not what I said. I said all expressions *evaluate to* pointers. This may well be true in particular implementations, but it is an implementation detail so Chris' point still stands. Another implementation could evaluate expressions to indices (as BCPL used to treat its globals), pieces of string or cheese, who knows? Those are all pointers. A pointer is something that points to a data object. (Slight sigh). Can I step in as a list owner and ask the people who are so very fond of debating this topic again and again: please let it drop. Threads such as this can remain interesting when the discussion generates a better understanding of the subject matter as the contributors are forced to articulate their positions leading to some kind of convergence of understanding. However, even if this were the only iteration of this debate, it would be clear by now that there's no chance of a simple "I see what you mean" moment. And this is far from the only iteration, even in the past few months. I feel for your need to demonstrate the validity of your respective positions. But it has moved on from being an enlightening debate and into the realms of mere tedium. Thanks. TJG -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
On Tue, Sep 26, 2017 at 5:36 AM, Marko Rauhamaa wrote: > Chris Angelico : >> You need *some* support for your assertion that there are pointers, > > What would convince you? Evidence, or a statement from the documentation. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
Rhodri James : > On 25/09/17 15:26, Marko Rauhamaa wrote: >> That's not what I said. I said all expressions *evaluate to* pointers. > > This may well be true in particular implementations, but it is an > implementation detail so Chris' point still stands. Another > implementation could evaluate expressions to indices (as BCPL used to > treat its globals), pieces of string or cheese, who knows? Those are all pointers. A pointer is something that points to a data object. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
On Tue, Sep 26, 2017 at 5:35 AM, Marko Rauhamaa wrote: > Chris Angelico : > >> On Tue, Sep 26, 2017 at 12:26 AM, Marko Rauhamaa wrote: >> Sorry, that was my bad in the terminology. But where do you get that >> all Python expressions evaluate to pointers? > > What do they evaluate to if not pointers? Anton's "identities" would > work, too. "Address" would do, as well. I have previously proposed the > term "leash." Call it "link" or "handle" or "arrow" if you want to. > > The term used isn't important. What's important is to understand that > each expression and subexpression produces and operates on pointers. They evaluate to objects. Not to pointers to objects. Not to references to objects. To objects. Expressions evaluate to actual objects, and when you assign "name = value", you bind the name to the object that value evaluates to. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
Chris Angelico : > You need *some* support for your assertion that there are pointers, What would convince you? Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
Chris Angelico : > On Tue, Sep 26, 2017 at 12:26 AM, Marko Rauhamaa wrote: > Sorry, that was my bad in the terminology. But where do you get that > all Python expressions evaluate to pointers? What do they evaluate to if not pointers? Anton's "identities" would work, too. "Address" would do, as well. I have previously proposed the term "leash." Call it "link" or "handle" or "arrow" if you want to. The term used isn't important. What's important is to understand that each expression and subexpression produces and operates on pointers. >> It also uses circular definitions when talking about dicts and lists: >> >>That object is then asked to assign the assigned object to the given >>attribute >> >>the sequence is asked to assign the assigned object to its item with >>that index. > > Technically, that's correct. When you use a statement like: > > foo[bar] = quux > > what it does is ask the object *foo* to assign *quux* to the item > represented by *bar*. What is missing is the definition of that assignment in the specific case of dicts and lists. The recursive definition must be well-founded. It covers variables ("names") but leaves the two other fundamental cases (dicts and lists) undefined. (I'm actually guessing the definition is missing because the author couldn't find good language for the cases. Apparently, "dict attribute binding" and "list element binding" weren't attractive enough.) > But you have yet to show how you can jump from "name binding" to > "pointer" using anything from the Python documentation. There's nothing to show. It's a simple matter of terminology. "Binding" is a passable synonym for "pointer." Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
On Tue, Sep 26, 2017 at 4:30 AM, Antoon Pardon wrote: > On 25-09-17 20:01, Chris Angelico wrote: >> On Tue, Sep 26, 2017 at 3:54 AM, Antoon Pardon >> wrote: >>> On 25-09-17 19:31, Chris Angelico wrote: If by "identity" you mean the integer values returned by id(), then nope, you're still wrong - there is no mapping from identities to values. There is a mapping from name to object/value, and from an object, you can determine its identity. If you like, there's a mapping from values to identities, but not the other way around. >>> >>> I'm describing this at a conceptual level. >> >> At what conceptual level are the identities an in-between state >> instead of being something you see from the object? >> Unless, of course, you can find something in the Python documentation that supports this two-step indirection? >>> >>> The fact that the Python documentation describes its sematics differently >>> doesn't contradict that this is a useful model. >> >> You need *some* support for your assertion that there are pointers, >> and you have absolutely none. > > I think you have me confused with Marko Rauhamaa. He makes an assertion > about pointers. I don't. My bad. It sounded like you were agreeing with Marko, and arguing the same assertion. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
On 25-09-17 20:01, Chris Angelico wrote: > On Tue, Sep 26, 2017 at 3:54 AM, Antoon Pardon > wrote: >> On 25-09-17 19:31, Chris Angelico wrote: >>> If by "identity" you mean the integer values returned by id(), then >>> nope, you're still wrong - there is no mapping from identities to >>> values. There is a mapping from name to object/value, and from an >>> object, you can determine its identity. If you like, there's a mapping >>> from values to identities, but not the other way around. >> >> I'm describing this at a conceptual level. > > At what conceptual level are the identities an in-between state > instead of being something you see from the object? > >>> Unless, of course, you can find something in the Python documentation >>> that supports this two-step indirection? >> >> The fact that the Python documentation describes its sematics differently >> doesn't contradict that this is a useful model. > > You need *some* support for your assertion that there are pointers, > and you have absolutely none. I think you have me confused with Marko Rauhamaa. He makes an assertion about pointers. I don't. -- Antoon Pardon. -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
On 25/09/17 15:26, Marko Rauhamaa wrote: Chris Angelico : On Mon, Sep 25, 2017 at 7:41 PM, Marko Rauhamaa wrote: In Python, all expressions evaluate pointers. And that's an assertion that isn't backed by anything in the Python specification. Where do you get that all Python expressions are pointers? That's not what I said. I said all expressions *evaluate to* pointers. This may well be true in particular implementations, but it is an implementation detail so Chris' point still stands. Another implementation could evaluate expressions to indices (as BCPL used to treat its globals), pieces of string or cheese, who knows? As for the specification, it doesn't make use of the word "pointer:" There's a reason for that... The (English) expression: The name is bound to the object. is just another way of saying: A pointer to the object is stored in the variable. It really isn't. -- Rhodri James *-* Kynesim Ltd -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
On Tue, Sep 26, 2017 at 3:54 AM, Antoon Pardon wrote: > On 25-09-17 19:31, Chris Angelico wrote: >> If by "identity" you mean the integer values returned by id(), then >> nope, you're still wrong - there is no mapping from identities to >> values. There is a mapping from name to object/value, and from an >> object, you can determine its identity. If you like, there's a mapping >> from values to identities, but not the other way around. > > I'm describing this at a conceptual level. At what conceptual level are the identities an in-between state instead of being something you see from the object? >> Unless, of course, you can find something in the Python documentation >> that supports this two-step indirection? > > The fact that the Python documentation describes its sematics differently > doesn't contradict that this is a useful model. You need *some* support for your assertion that there are pointers, and you have absolutely none. Sure, that's not contradicting anything, but it's like a scientist trying to prove that there's a link between laser pointers and cancer, and just never finding any backing for that theory. Nothing has yet DISproven that link, but how long do you search fruitlessly before you accept that maybe your theory is flat wrong? And it's hard to convince someone else of your theory if it has no support. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was re: [Tutor] beginning to code]
I would claim that these two paragraphs do not agree. What is stored in the variable in Pascal? In declared variables and value parameters, the value itself. Let's just temporarily stipulate that for reference parameters and pointer variables actually store a pointer to the object. Where is it recorded whether this is a pointer to an integer or a float or a character or a thingamajig? Neither in the value nor the assumed pointer to the variable. In Pascal (and most compiled languages) that value type is maintained separately by the compiler, and then discarded in the compiled code. In the case of Python, the 'pointer' you refer to also has no type information. Instead, the type of the value is frequently inferred at run-time, based on additional information stored with the value. There is no equivalent information available at run-time in Pascal. Now, when you say 'Python's assignment semantics are wholly contained by those of Pascal', please show me the equivalent Pascal code to mimic the following (and not by defining a brand new complex object type in Pascal, since I am not doing so in Python). x = 5 x = 'abc' I think the larger discussion was about value and reference parameters. Yes you can do both of those in Pascal. But if you were stuck with just those two choices, which applies to this function definition? def add_to_self(arg): arg += arg x = 'abc' add_to_self(x) # now x = 'abcabc' x = 5 add_to_self(x) # x is still 5 is 'arg' a value parameter or a reference parameter? Can you replicate this behavior in Pascal without any if statement, since, as you say, the semantics are wholly contained by those of Pascal (aside from the += operator itself not appearing in the Pascal language) Roger Christman Pennsylvania State Universtiy On Mon, Sep 25, 2017 12:00 PM, python-list@python.org wrote: > A pointer to the object is stored in the variable. > >Of course, I'm using terminology that is not conventional in Python >circles. However, I'm doing it to demonstrate that there's nothing >particularly different between Python's assignment semantics and those >of, say, Pascal. Python's assignment semantics are wholly contained by >those of Pascal. > > -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
On 25-09-17 19:31, Chris Angelico wrote: > On Tue, Sep 26, 2017 at 3:04 AM, Antoon Pardon > wrote: >> On 25-09-17 16:29, Marko Rauhamaa wrote: >>> Antoon Pardon : >>> Op 25-09-17 om 15:16 schreef Marko Rauhamaa: > No, I'm not. I'm talking about pointers in the abstract sense, both in > case of Python and Pascal. Neither language gives any hint as to the > physical nature of the pointer. Yes you are. Python doesn't have pointers at the language level. So if you start talking pointers you are talking about implementations however abstract. >>> >>> It is difficult to say what is the "native" Python term for the thing. >>> "Binding," maybe? The language spec fails to give it a name. >>> >>> However, when comparing different languages, you had better unify the >>> terminology or you'll be confused by purely terminological issues. >> >> Fine, you have two mappings, a mapping from names to identities and a >> mapping from identities to values. In languages like C, Pascal, ... >> an assignment changes the mapping between the identities and the >> values. In languages like Python, Smalltalk, ... an assignment >> changes the mapping between the names and the identities. > > If by "identity" you mean the integer values returned by id(), then > nope, you're still wrong - there is no mapping from identities to > values. There is a mapping from name to object/value, and from an > object, you can determine its identity. If you like, there's a mapping > from values to identities, but not the other way around. I'm describing this at a conceptual level. > Unless, of course, you can find something in the Python documentation > that supports this two-step indirection? The fact that the Python documentation describes its sematics differently doesn't contradict that this is a useful model. -- Antoon Pardon. -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
On Tue, Sep 26, 2017 at 12:26 AM, Marko Rauhamaa wrote: > Chris Angelico : > >> On Mon, Sep 25, 2017 at 7:41 PM, Marko Rauhamaa wrote: >>> In Python, all expressions evaluate pointers. >> >> And that's an assertion that isn't backed by anything in the Python >> specification. Where do you get that all Python expressions are >> pointers? > > That's not what I said. I said all expressions *evaluate to* pointers. Sorry, that was my bad in the terminology. But where do you get that all Python expressions evaluate to pointers? > As for the specification, it doesn't make use of the word "pointer:" > >https://docs.python.org/3/reference/simple_stmts.html#assignme >nt-statements> > > Instead, it uses (English) expressions like: > >is bound to the object >is rebound > > when talking about "names" (aka variables). Yeah exactly. It doesn't say anything about them being pointers. Because they aren't. > It also uses circular definitions when talking about dicts and lists: > >That object is then asked to assign the assigned object to the given >attribute > >the sequence is asked to assign the assigned object to its item with >that index. Technically, that's correct. When you use a statement like: foo[bar] = quux what it does is ask the object *foo* to assign *quux* to the item represented by *bar*. > The (English) expression: > >The name is bound to the object. > > is just another way of saying: > >A pointer to the object is stored in the variable. Where does this come from? If the name "Rosuav" refers to me, does that mean, in English, that there is a pointer to me stored in the variable named "Rosuav"? English isn't implemented in C or Pascal. > Of course, I'm using terminology that is not conventional in Python > circles. However, I'm doing it to demonstrate that there's nothing > particularly different between Python's assignment semantics and those > of, say, Pascal. Python's assignment semantics are wholly contained by > those of Pascal. As long as you start by defining everything in terms of Pascal, yes, you can then prove that everything is contained in Pascal semantics. But you have yet to show how you can jump from "name binding" to "pointer" using anything from the Python documentation. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
On Tue, Sep 26, 2017 at 3:04 AM, Antoon Pardon wrote: > On 25-09-17 16:29, Marko Rauhamaa wrote: >> Antoon Pardon : >> >>> Op 25-09-17 om 15:16 schreef Marko Rauhamaa: No, I'm not. I'm talking about pointers in the abstract sense, both in case of Python and Pascal. Neither language gives any hint as to the physical nature of the pointer. >>> >>> Yes you are. Python doesn't have pointers at the language level. So if >>> you start talking pointers you are talking about implementations >>> however abstract. >> >> It is difficult to say what is the "native" Python term for the thing. >> "Binding," maybe? The language spec fails to give it a name. >> >> However, when comparing different languages, you had better unify the >> terminology or you'll be confused by purely terminological issues. > > Fine, you have two mappings, a mapping from names to identities and a > mapping from identities to values. In languages like C, Pascal, ... > an assignment changes the mapping between the identities and the > values. In languages like Python, Smalltalk, ... an assignment > changes the mapping between the names and the identities. If by "identity" you mean the integer values returned by id(), then nope, you're still wrong - there is no mapping from identities to values. There is a mapping from name to object/value, and from an object, you can determine its identity. If you like, there's a mapping from values to identities, but not the other way around. Unless, of course, you can find something in the Python documentation that supports this two-step indirection? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
On 25-09-17 16:29, Marko Rauhamaa wrote: > Antoon Pardon : > >> Op 25-09-17 om 15:16 schreef Marko Rauhamaa: >>> No, I'm not. I'm talking about pointers in the abstract sense, both in >>> case of Python and Pascal. Neither language gives any hint as to the >>> physical nature of the pointer. >> >> Yes you are. Python doesn't have pointers at the language level. So if >> you start talking pointers you are talking about implementations >> however abstract. > > It is difficult to say what is the "native" Python term for the thing. > "Binding," maybe? The language spec fails to give it a name. > > However, when comparing different languages, you had better unify the > terminology or you'll be confused by purely terminological issues. Fine, you have two mappings, a mapping from names to identities and a mapping from identities to values. In languages like C, Pascal, ... an assignment changes the mapping between the identities and the values. In languages like Python, Smalltalk, ... an assignment changes the mapping between the names and the identities. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
Chris Angelico : > On Mon, Sep 25, 2017 at 7:41 PM, Marko Rauhamaa wrote: >> In Python, all expressions evaluate pointers. > > And that's an assertion that isn't backed by anything in the Python > specification. Where do you get that all Python expressions are > pointers? That's not what I said. I said all expressions *evaluate to* pointers. As for the specification, it doesn't make use of the word "pointer:" https://docs.python.org/3/reference/simple_stmts.html#assignme nt-statements> Instead, it uses (English) expressions like: is bound to the object is rebound when talking about "names" (aka variables). It also uses circular definitions when talking about dicts and lists: That object is then asked to assign the assigned object to the given attribute the sequence is asked to assign the assigned object to its item with that index. The (English) expression: The name is bound to the object. is just another way of saying: A pointer to the object is stored in the variable. Of course, I'm using terminology that is not conventional in Python circles. However, I'm doing it to demonstrate that there's nothing particularly different between Python's assignment semantics and those of, say, Pascal. Python's assignment semantics are wholly contained by those of Pascal. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
Antoon Pardon : > Op 25-09-17 om 15:16 schreef Marko Rauhamaa: >> No, I'm not. I'm talking about pointers in the abstract sense, both in >> case of Python and Pascal. Neither language gives any hint as to the >> physical nature of the pointer. > > Yes you are. Python doesn't have pointers at the language level. So if > you start talking pointers you are talking about implementations > however abstract. It is difficult to say what is the "native" Python term for the thing. "Binding," maybe? The language spec fails to give it a name. However, when comparing different languages, you had better unify the terminology or you'll be confused by purely terminological issues. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
On Mon, Sep 25, 2017 at 7:41 PM, Marko Rauhamaa wrote: > Antoon Pardon : > >> the semantics of an assignment depends on the language > > I've only seen one kind of assignment in the general-purpose programming > languages I know, maybe with the exception of Prolog and Rust. > > So the assignment is the same everywhere, only the evaluation model > varies. In classic C, expressions evaluate to integers, double-precision > floating-point numbers or pointers. In Python, all expressions evaluate > pointers. And that's an assertion that isn't backed by anything in the Python specification. Where do you get that all Python expressions are pointers? That's a construct invented specifically to shoe-horn Python into "hey look it's pass by value". It's not the fundamental of the language. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
Op 25-09-17 om 15:16 schreef Marko Rauhamaa: > Antoon Pardon : > >> Op 25-09-17 om 14:16 schreef Marko Rauhamaa: >>> Python only operates with pointers. You can operate with pointers in >>> Pascal as well. >> You are talking about implementation details. > No, I'm not. I'm talking about pointers in the abstract sense, both in > case of Python and Pascal. Neither language gives any hint as to the > physical nature of the pointer. Yes you are. Python doesn't have pointers at the language level. So if you start talking pointers you are talking about implementations however abstract. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
Antoon Pardon : > Op 25-09-17 om 14:16 schreef Marko Rauhamaa: >> Python only operates with pointers. You can operate with pointers in >> Pascal as well. > > You are talking about implementation details. No, I'm not. I'm talking about pointers in the abstract sense, both in case of Python and Pascal. Neither language gives any hint as to the physical nature of the pointer. All Python expressions evaluate to pointers (or handles or references; call them whatever you want). All Python "lvalues" hold pointers. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
Op 25-09-17 om 14:16 schreef Marko Rauhamaa: > Antoon Pardon : > >> Op 25-09-17 om 13:32 schreef Marko Rauhamaa: >>> In Python, assignment "mutates the target" as well. It's only that in >>> Python, the target is always a pointer. >> Fine if you want to word it like that, the assignments in Pascal and >> Python are still sufficiently different. >> >> If you do A := B in Pascal, you have two different entities with equal >> values. >> >> If you do A = B in Python, you have one entity that is refered to by >> two variables/names. > Python only operates with pointers. You can operate with pointers in > Pascal as well. You are talking about implementation details. That under the hood you can implement it all by manipulating bits in registers and memory, doesn't contradict that the semantic model is different. -- Antoon Pardon. -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
Antoon Pardon : > Op 25-09-17 om 13:32 schreef Marko Rauhamaa: >> In Python, assignment "mutates the target" as well. It's only that in >> Python, the target is always a pointer. > > Fine if you want to word it like that, the assignments in Pascal and > Python are still sufficiently different. > > If you do A := B in Pascal, you have two different entities with equal > values. > > If you do A = B in Python, you have one entity that is refered to by > two variables/names. Python only operates with pointers. You can operate with pointers in Pascal as well. Say I have (in Pascal): new(A); B := A Then, in Pascal, you have one entity that is referred to by two variables/names. > The difference becomes clear if you later mutate A or B. In the case > of Pascal, you will have mutated one of two entities and the other > entity remains the same. In the case of Python, you will have mutated > the one entity that both A and B refer to and so the mutations will be > visible through the other variable/name. Continuing the Pascal example above: new(A); B := A; { one entity, two names } A^ := 3;{ mutate the one entity } writeln(B); A^ := 7;{ mutate the one entity again } writeln(B) will output 3 7 (although I haven't programmed anything in Pascal for than 30 years so my syntax may be off). Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
Op 25-09-17 om 13:32 schreef Marko Rauhamaa: > Antoon Pardon : > >> Op 25-09-17 om 11:41 schreef Marko Rauhamaa: >>> Antoon Pardon : >>> the semantics of an assignment depends on the language >>> I've only seen one kind of assignment in the general-purpose >>> programming languages I know, maybe with the exception of Prolog and >>> Rust. >> I disagree. In languages like Pascal an asignment mutates the target >> that the left hand refers to, by copying over the value from the right >> side. In languages like python an asignment lets the target refer to a >> new entity. > In Python, assignment "mutates the target" as well. It's only that in > Python, the target is always a pointer. Fine if you want to word it like that, the assignments in Pascal and Python are still sufficiently different. If you do A := B in Pascal, you have two different entities with equal values. If you do A = B in Python, you have one entity that is refered to by two variables/names. The difference becomes clear if you later mutate A or B. In the case of Pascal, you will have mutated one of two entities and the other entity remains the same. In the case of Python, you will have mutated the one entity that both A and B refer to and so the mutations will be visible through the other variable/name. -- Antoon Pardon. -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
Antoon Pardon : > Op 25-09-17 om 11:41 schreef Marko Rauhamaa: >> Antoon Pardon : >> >>> the semantics of an assignment depends on the language >> I've only seen one kind of assignment in the general-purpose >> programming languages I know, maybe with the exception of Prolog and >> Rust. > > I disagree. In languages like Pascal an asignment mutates the target > that the left hand refers to, by copying over the value from the right > side. In languages like python an asignment lets the target refer to a > new entity. In Python, assignment "mutates the target" as well. It's only that in Python, the target is always a pointer. Here's proof (up to isomorphism): >>> x = object() >>> y = object() >>> id(x) 139719622467712 >>> x = y >>> id(x) 139719622467728 Meaning. Before: +-- x --+ |139719622467712| +---+ After: +-- x --+ |139719622467728| +---+ So we can see the contents of x have been mutated. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
Op 25-09-17 om 11:41 schreef Marko Rauhamaa: > Antoon Pardon : > >> the semantics of an assignment depends on the language > I've only seen one kind of assignment in the general-purpose programming > languages I know, maybe with the exception of Prolog and Rust. I disagree. In languages like Pascal an asignment mutates the target that the left hand refers to, by copying over the value from the right side. In languages like python an asignment lets the target refer to a new entity. -- Antoon Pardon. -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
Antoon Pardon : > the semantics of an assignment depends on the language I've only seen one kind of assignment in the general-purpose programming languages I know, maybe with the exception of Prolog and Rust. So the assignment is the same everywhere, only the evaluation model varies. In classic C, expressions evaluate to integers, double-precision floating-point numbers or pointers. In Python, all expressions evaluate pointers. For example, in C, the expression 1 + 2 takes two integers and produces a third one. By contrast, the same Python expression takes two pointers and produces a third one (while possibly generating a number of objects in the process). Analogously, C lvalues can store various types of value. In Python, all "lvalues" store a pointer. I haven't wanted to use the word "value" above because it is ambiguous and confusing in the context of this discussion. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
Op 25-09-17 om 00:39 schreef Gregory Ewing: > Dennis Lee Bieber wrote: >> "Binding" itself tends to be Python specific terminology -- in >> that it >> is the parameter /name/ that gets bound/attached to the argument >> /object/. >> It is the same method as used in any Python "assignment" statement, > > Which is why I think "call by assignment" would be > a much better term! > But since the semantics of an assignment depends on the language, "call by assignment" says nothing abouth the semantics of the parameter passing. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
Steve D'Aprano wrote: I think that suffers from the same problem as "call by binding" -- assignment is too general a word. If you're learning a new language, you're almost certainly going to learn how assignment works in that language before you get as far as worrying about parameter passing. If not, you need to find out. The only case where it wouldn't be appropriate is if the language doesn't have assignment, in which case "call by binding" or whatever terminology it uses for naming things would be better. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
Dennis Lee Bieber wrote: Though "assignment" differs so much between languages That's the point of the term -- it's the same as whatever assignment does in the language concerned. This is true of *every* language I know of that uses the term "call by value" in its official documentation. It's also true of those that use some other term such as "call by object" or "call by binding". -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
On 09/24/2017 09:56 AM, Dennis Lee Bieber wrote: > "Binding" itself tends to be Python specific terminology Not so. How it's used in Python terminology is fairly closely aligned with how the word was used in my programming language theory class at uni, where it was defined in mathematical terms and lambda calculus rather than in terms of computer memory. This is one area that Python really appealed to me. Many of its concepts are more closely aligned with the theories and calculus we studied in tour theory class. I suppose this is also why Lisp (we used Scheme in our class) is so appealing to some. -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
On Mon, 25 Sep 2017 08:39 am, Gregory Ewing wrote: > Dennis Lee Bieber wrote: >> "Binding" itself tends to be Python specific terminology -- in that it "Binding" is certainly not Python-specific: https://en.wikipedia.org/wiki/Name_binding and here's an example of the term in use: https://www.gnu.org/software/sather/docs-1.2/tutorial/fortran-names.html >> is the parameter /name/ that gets bound/attached to the argument /object/. >> It is the same method as used in any Python "assignment" statement, > > Which is why I think "call by assignment" would be > a much better term! I think that suffers from the same problem as "call by binding" -- assignment is too general a word. The Pascal assignment: a := b; copies the value of b to the storage position represented by a. That's precisely the same thing that occurs when you call func(b), so one might equally say that Pascal was call by assignment. Likewise for C assignment. Pascal doesn't have "reference variables", so there is no assignment analogue to calling a function with a var parameter. But C++ does have reference variables, to we can say that assignment: a = b; is the same as function call func(b) regardless of whether C++ is using by-value or by-reference semantics. So I believe that either "call by binding" or "call by assignment" could both equally apply to any and all languages with function parameters, regardless of implementation or the language's defined semantics. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
On Mon, 25 Sep 2017 01:56 am, bartc wrote: >> The point I am making is that we could describe just about any and all >> languages with functions "call by binding", whether they are call by value >> like C, call by reference like Fortran, call by need like Haskell, or call by >> sharing like Python. > > Then 'binding' is either ill-defined or used wrongly. No, binding is a perfectly fine word. It is just too generic to be helpful here. In Pascal or C: a := b; a = b; the compiler binds a copy of the value*of b to the identifier a. In C++ were we have reference variables: a = b; will either bind a copy of b to a, same as C, or bind a reference to b to a (thus making a an alias to b). In Python: a = b binds the value of b to a, without copying. If it weren't too late to change decades of use, I'd say that "pass by value" should be called "pass by copying". The nature of the binding can differ: Pascal and C use the "variables are a numbered box" model, while Python uses the "variables are one end of piece of string tied to the object" model. Name binding is a generic term, like assignment, which doesn't really hint at how the assignment is done. All it really means is that the R-value (the right hand side of the assignment, an expression or literal or value of some sort) is associated with the L-value (the left hand side of the assignment, a variable name, or identifier, of some sort). By the way, the model of "pieces of string" to describe Python's assignment model leaks too. (All models leak, to a lesser or greater degree.) The problem with the model is that if you tied a piece of string to an object, the object can follow the string backwards to find out its name (or names). But in Python, objects cannot do that: they have no way of telling what names they are known by, or even how many names there are. (There may be clever tricks you can play with the garbage collector or debugger, but that's not part of Python-the-language, that's a compiler-specific hook which can peer into the implementation.) -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
Dennis Lee Bieber wrote: "Binding" itself tends to be Python specific terminology -- in that it is the parameter /name/ that gets bound/attached to the argument /object/. It is the same method as used in any Python "assignment" statement, Which is why I think "call by assignment" would be a much better term! -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Call by binding [was Re: [Tutor] beginning to code]
On 24/09/2017 15:49, Steve D'Aprano wrote: On Mon, 25 Sep 2017 12:35 am, Stefan Ram wrote: WRT to assertions about Python, I try to base them on the "The Python Language Reference, Release 3.6.0" (PRL). So, WRT to parameter passing, I would use this part of the PRL: »The following constructs bind names: formal parameters to functions,« PRL 4.2.1 . Therefore, what Python does, I'd call »call by binding«. I am not aware of "call by binding" being a well-known or recognised term. Did you make it up? Also, the problem is that *any* form of function call binds *something* to the function parameters. If we consider the Pascal declaration: procedure proc(x: integer; var y: integer); and then we call it: var a, b: integer; begin a := 1; b := 2; proc(a, b); end. then 1 is bound to x and 2 is bound to y. They happen to exist in different scopes (x is local to proc, the *name* y is local to proc, but the variable is bound to y is global) but that's not important. The point I am making is that we could describe just about any and all languages with functions "call by binding", whether they are call by value like C, call by reference like Fortran, call by need like Haskell, or call by sharing like Python. Then 'binding' is either ill-defined or used wrongly. Imagine that each name (a,b,x,y) is a little box. In Pascal, the boxes for a and b contain 1 and 2 respectively. For x and y, they contain pointers (dereferenced behind the scenes). Fortran is similar (or Fortran IV was; I don't know modern ones). C works the same way: every variable has a box, and that box directly contains a value. In Python, those boxes don't contain anything, except one end of a piece of string. The other end is attached to an object. When you pass a variable to a function like this: def fn(X): A=1 fn(A) Then X gets set up with a string which has the same object at the other end as A. (And the object might have a reference count to reflect that extra string.) This is why you can't change A in the caller as there is no way to get from X's box to A's box. And the strings to the object are one-way. In the case of fn(A+2), a new object is created (with value '3', or an existing '3' might be used), a new string is attached to it, and the other is attached to X. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Call by binding [was Re: [Tutor] beginning to code]
On Mon, 25 Sep 2017 12:35 am, Stefan Ram wrote: > WRT to assertions about Python, I try to base them on the > "The Python Language Reference, Release 3.6.0" (PRL). > > So, WRT to parameter passing, I would use this part of the PRL: > > »The following constructs bind names: formal parameters > to functions,« PRL 4.2.1 > > . Therefore, what Python does, I'd call »call by binding«. I am not aware of "call by binding" being a well-known or recognised term. Did you make it up? Also, the problem is that *any* form of function call binds *something* to the function parameters. If we consider the Pascal declaration: procedure proc(x: integer; var y: integer); and then we call it: var a, b: integer; begin a := 1; b := 2; proc(a, b); end. then 1 is bound to x and 2 is bound to y. They happen to exist in different scopes (x is local to proc, the *name* y is local to proc, but the variable is bound to y is global) but that's not important. The point I am making is that we could describe just about any and all languages with functions "call by binding", whether they are call by value like C, call by reference like Fortran, call by need like Haskell, or call by sharing like Python. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list