Re: Aliasing [was Re: [Tutor] beginning to code]

[ROGER GRAYDON CHRISTMAN]

On Tue, Sep 26, 2017 11:00 PM, Steve D'Aprano 
wrote:
>
The critical distinction here is whether the names refer to each other:
>
>a <---> b
>
>or whether they merely refer to the same value:
>
>a ---> [ value ] <--- b
>
>
>Python uses the second model. Var parameters in Pascal and references in C++
use
>the first. Since the term "aliasing" is well-established for the first, using
>it in Python *without making the difference clear* is wrong.
>
>
>

Aha!  There is the fundamental problem.
In your first diagram below, if a is a pointer to b, and b is a pointer to a,
then where is the value?

If the value of 1 (or 2) is in a, then a cannot point at b;

Or are you saying now that all variables in Pascal and C
are _both_ values and pointers, simultaneously?

Does that mean then that the value 1 (or 2) is in _both_  a and b?
So that an assignment to either must change both copies of the value?

No, I think it is more likely to be that the second diagram applies
in all cases.   Simply declaring a variable like A would lead to

a --> [ uninitialized ]

int& b creates an alias to a leads to

a -> [ uninitialized ] <- b

and then any assignment to a or b in the non-Python languages
under consideration would fill in that box, allowing the change
to be visible to both.

But in Python, _all_ assignments are aliases.

And I'll leave off further discussion by referring back to my
previous note about what happens when we do "b = c"
in the non-Python languages and in Python.

>From the ordering of the notes in this forum, I will just assume
you did not get a chance to read it before this post I am responding to.

Roger Christman
Pennsylvania State University

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

Re: Aliasing [was Re: [Tutor] beginning to code]

[Antoon Pardon]

Op 27-09-17 om 09:38 schreef Steven D'Aprano:

No, the model that C++ and Pascal use is not different in this aspect.

> that Pascal var parameters and C++ reference variables operate the same 
> way as Python variable assignment, the *kindest* thing I can say is that 
> you are ignorant.

The kindest thing I can say about you is that you are very confused
at a specific level. A confusion that is illustrated by your 
contribution at 
https://mail.python.org/pipermail/python-list/2017-September/726513.html
and of which you seem to totally ignore my resonse at 
https://mail.python.org/pipermail/python-list/2017-September/726527.html

> Python does not have anything like C++ references and Pascal var 
> parameters, which is why you will never be able to write a swap() 
> function that operates like the classic Pascal swap procedure used as the 
> definitive test for pass-by-reference.

You keep repeating this and you keep ignoring my counter argument.
The fact that you can write a swap procedure in C++ and Pascal
is not because the parameter passing semantics are different but
because the assignment semantics are different.

I already explained that a working swap function depends on two
conditions:

1) Reference paramaters
2) A general way in which the object a name refers to can be
   modified/mutated (In a language like Pascal that is the
   assignment).

You keep asserting that not being able to write a swap means we
don't have condition (1), while ignoring we know we don't have
condition (2) in Python.

> Twice you have claimed to be able to write such a swap procedure for 
> lists. You can't. If you think you can, it is only because you have 
> misunderstood the problem and are writing something else that does 
> something different from what the Pascal version does.

I already posted code once, here it is again:

ls1 = [1, 3, 5, 7]
ls2 = [2, 4, 6]

def list_swap(lp1, lp2):

tmp = [] # pseudo declaration

tmp[:] = lp1 # 
lp1[:] = lp2 #  This is more or less how array assignments work in Pascal
lp2[:] = tmp #

print("ls1 =", ls1)
print("ls2 =", ls2)

list_swap(ls1, ls2)

print()
print("ls1 =", ls1)
print("ls2 =", ls2)

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

Re: Aliasing [was Re: [Tutor] beginning to code]

[Antoon Pardon]

Op 27-09-17 om 10:11 schreef Chris Angelico:
> On Wed, Sep 27, 2017 at 5:38 PM, Steven D'Aprano
>  wrote:
>> Twice you have claimed to be able to write such a swap procedure for
>> lists. You can't. If you think you can, it is only because you have
>> misunderstood the problem and are writing something else that does
>> something different from what the Pascal version does.
> I suspect what he's thinking of is a swap_contents() function, which
> gives the appearance that the lists have been swapped. That's entirely
> possible, but doesn't actually achieve what swap() does.

If you refer to languages like Pascal or C, for illustrating that you
can write a swap function in them, the swapping that happens there is
one of content. So claiming that swapping contend doesn't actually
achieves whar swap() does, seems wrong.

-- 
Antoon Pardon.

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

Re: Aliasing [was Re: [Tutor] beginning to code]

[Chris Angelico]

On Wed, Sep 27, 2017 at 5:38 PM, Steven D'Aprano
 wrote:
> Twice you have claimed to be able to write such a swap procedure for
> lists. You can't. If you think you can, it is only because you have
> misunderstood the problem and are writing something else that does
> something different from what the Pascal version does.

I suspect what he's thinking of is a swap_contents() function, which
gives the appearance that the lists have been swapped. That's entirely
possible, but doesn't actually achieve what swap() does.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Aliasing [was Re: [Tutor] beginning to code]

[Steven D'Aprano]

On Wed, 27 Sep 2017 08:56:03 +0200, Antoon Pardon wrote:

>> But that's not enough for the variable b to be an alias for the
>> variable a.
> 
> Yes it is!


Since you seem to be intent on inventing your own meanings for well 
established words, for the confusion and misinformation of all, I can 
only follow in your footsteps and say:

"You are a fine fellow and your arguments make perfect sense."

Make if that what you will.


Antoon, there is no point in continuing this argument. You're entitled to 
your own opinions, but not your own facts, so when you insist:

> No, the model that C++ and Pascal use is not different in this aspect.

that Pascal var parameters and C++ reference variables operate the same 
way as Python variable assignment, the *kindest* thing I can say is that 
you are ignorant.

Python does not have anything like C++ references and Pascal var 
parameters, which is why you will never be able to write a swap() 
function that operates like the classic Pascal swap procedure used as the 
definitive test for pass-by-reference.

Twice you have claimed to be able to write such a swap procedure for 
lists. You can't. If you think you can, it is only because you have 
misunderstood the problem and are writing something else that does 
something different from what the Pascal version does.



-- 
Steven D'Aprano
“You are deluded if you think software engineers who can't write 
operating systems or applications without security holes, can write 
virtualization layers without security holes.” —Theo de Raadt
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Aliasing [was Re: [Tutor] beginning to code]

[Antoon Pardon]

Op 27-09-17 om 04:58 schreef Steve D'Aprano:
> A pedantic difference that makes no difference to my argument.
>
> I see that you ignored the later assignment:
>
> b = 2;
>
> which also assigned to a. *That** is the fundamental point: b is certainly an
> alias for a, and assigning to b assigns to a.
>
> That's how aliases work in C++. That's how var parameters in Pascal work, and
> out parameters in Ada. That is what it means to say that "b is an alias to a".

The main problem is that you keep using assignment as if an assignment in
languages like Pascal and C++ has an similar effect like as assignment in
Python and thus that if an assignment has an effect in one language it should
have that effect in other languages.

In C++ and Pascal talking about an assignment means, that we have a name that
refers to an object whose value was overwritten.

In Python an assignment means that we have name that will now refer to an other
object.

If two names are aliases they refer to the same object and when the value of 
that
object is modified through one name, it is visible through the other name. How
one modified that object is immaterial. It doesn't matter whether the 
modification/mutation was done through an asignment or an other kind of 
mutation.

It also doesn't matter what the label is, we use for the operation. The label
"assignment" is not magic. If in one context an assignment mutates and in an
other context it doesn't you can't interfere conclusions about the assignment
in the second context based on the effects an assignment has in the first 
context
because we are talking about two differnt operations that just use the same 
lable.

-- 
Antoon Pardon.


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

Re: Aliasing [was Re: [Tutor] beginning to code]

[Antoon Pardon]

Op 27-09-17 om 04:58 schreef Steve D'Aprano:
> On Wed, 27 Sep 2017 02:03 am, Stefan Ram wrote:
>
>> Steve D'Aprano  writes:
>>> On Tue, 26 Sep 2017 03:26 am, Antoon Pardon wrote:
 at that moment, but it still needed correction. If the assignment is
 an alias operator then after the statements
>>> Here's some C++ code that demonstrates it. Apologies in advance if it isn't
>>> the most idiomatic C++ code.
>>   In C++, assignments and initializations are different
>>   concepts.
>>
>>> int& b = a;  // reference variable or alias
>>   This is an initialization, not an assignment.
> A pedantic difference that makes no difference to my argument.
>
> I see that you ignored the later assignment:
>
> b = 2;
>
> which also assigned to a. *That** is the fundamental point: b is certainly an
> alias for a, and assigning to b assigns to a.
>
> That's how aliases work in C++. That's how var parameters in Pascal work, and
> out parameters in Ada. That is what it means to say that "b is an alias to a".
>
> b is another name for the *variable* a, not just whatever value a happens to
> hold now.
>
> I say that assignment in Python is NOT an aliasing operation. Antoon claims 
> I'm
> wrong, and his evidence is:
>
> a = []
> b = a  # Antoon says this is an alias operation
> b.append(1)
> assert a == [1]
>
>
> But that's not enough for the variable b to be an alias for the variable a.

Yes it is!

> Antoon is correct that a and b are two different names for the same list, but
> the two variables are not aliases to each other because assignments to b do 
> not
> affect a, and vice versa.

You are hitting your blindspot again and ignore that in languages like Pascal 
...
an assignment is a copy operation and thus mutates the variable that is assigned
to. Two variables are aliases for each other if they are the same object and so
when one mutates the object seen through one name, the mutation is visible 
through
the other.

Since Python in Python an assignent doesn't mutate the object but makes it an 
alias of an other object it is wrong to expect in python that an assignment
to one of an alias which would break the alias, would have the same effect
as in a language where an assignemt to one of an alias would mutate the 
variable. 

> A good test for aliasing is to take the source code and mechanically replace
> every occurrence of the alias (in the same scope of course) with the original,

No it is not. You forget the possibility that two names can be aliases at
one point but no longer are at an other point. 

> or vice versa, and see whether the meaning of the code changes.
>
> In C++, apart from the initial binding:
>
> int& b = a;
>
> ("initialisation") you could now randomly swap a for b or b for a and the
> meaning of the code will not change.

That is only true for as long a and b remain aliases. As soon as an operation
is excuted that makes a and b no longer aliases, your test fails. Sure in
a language like C++ such an alias can't be broken, but aliases are broken
in Python all the time because that is what assignment do, break some
aliases and forge new ones.

> But in Python, if we try the same trick, the code *does* change:
>
> a = 1
> b = a
> b = 2
>
> *is not* the same as:
>
> a = 1
> b = a
> a = 2
>
>
> (1) In Pascal, Ada, C++ etc using a reference variable (or var parameter, or
> whatever terminology they use) makes the two names aliases to EACH OTHER, not
> to the value they are bound to.

No using a reference variable makes the two names aliases to the same 
object/entity.
So that if you mutate it through one name, the mutation is visible through the
other name. The effect you see in those languages with assignments via one
name are explained by the fact that assignment is a mutating operation.

> (2) In Python, Javascript, Ruby etc assignment can give you two names for the
> same object, but the names do not alias each other.
>
> The critical distinction here is whether the names refer to each other:
>
> a <---> b

In languages like C++, Pascal, ... aliases don't mean the names refer to
each other. Names/Identifiers refering to each other is non sensical in
those languages.

>
> or whether they merely refer to the same value:
>
> a ---> [ value ] <--- b
>
>
> Python uses the second model. Var parameters in Pascal and references in C++ 
> use
> the first. Since the term "aliasing" is well-established for the first, using
> it in Python *without making the difference clear* is wrong.

No, the model that C++ and Pascal use is not different in this aspect.

-- 
Antoon Pardon.


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

Re: Aliasing [was Re: [Tutor] beginning to code]

[Bill]

Steve D'Aprano wrote:

On Wed, 27 Sep 2017 02:03 am, Stefan Ram wrote:


Steve D'Aprano  writes:

On Tue, 26 Sep 2017 03:26 am, Antoon Pardon wrote:

at that moment, but it still needed correction. If the assignment is
an alias operator then after the statements

Here's some C++ code that demonstrates it. Apologies in advance if it isn't
the most idiomatic C++ code.

   In C++, assignments and initializations are different
   concepts.


int& b = a;  // reference variable or alias

   This is an initialization, not an assignment.

A pedantic difference that makes no difference to my argument.

I see that you ignored the later assignment:

b = 2;

which also assigned to a. *That** is the fundamental point: b is certainly an
alias for a, and assigning to b assigns to a.

That's how aliases work in C++. That's how var parameters in Pascal work, and
out parameters in Ada. That is what it means to say that "b is an alias to a".

b is another name for the *variable* a, not just whatever value a happens to
hold now.

I say that assignment in Python is NOT an aliasing operation. Antoon claims I'm
wrong, and his evidence is:

a = []
b = a  # Antoon says this is an alias operation
b.append(1)
assert a == [1]


But that's not enough for the variable b to be an alias for the variable a.

Antoon is correct that a and b are two different names for the same list, but
the two variables are not aliases to each other because assignments to b do not
affect a, and vice versa.

A good test for aliasing is to take the source code and mechanically replace
every occurrence of the alias (in the same scope of course) with the original,
or vice versa, and see whether the meaning of the code changes.

In C++, apart from the initial binding:

 int& b = a;

("initialisation") you could now randomly swap a for b or b for a and the
meaning of the code will not change.

But in Python, if we try the same trick, the code *does* change:

a = 1
b = a
b = 2

*is not* the same as:

a = 1
b = a
a = 2


(1) In Pascal, Ada, C++ etc using a reference variable (or var parameter, or
whatever terminology they use) makes the two names aliases to EACH OTHER, not
to the value they are bound to.

(2) In Python, Javascript, Ruby etc assignment can give you two names for the
same object, but the names do not alias each other.

The critical distinction here is whether the names refer to each other:

a <---> b

or whether they merely refer to the same value:

a ---> [ value ] <--- b


Python uses the second model. Var parameters in Pascal and references in C++ use
the first. Since the term "aliasing" is well-established for the first, using
it in Python *without making the difference clear* is wrong.




That is a very nice argument!  : )
--
https://mail.python.org/mailman/listinfo/python-list

Re: Aliasing [was Re: [Tutor] beginning to code]

[Steve D'Aprano]

On Wed, 27 Sep 2017 02:03 am, Stefan Ram wrote:

> Steve D'Aprano  writes:
>>On Tue, 26 Sep 2017 03:26 am, Antoon Pardon wrote:
>>>at that moment, but it still needed correction. If the assignment is
>>>an alias operator then after the statements
>>Here's some C++ code that demonstrates it. Apologies in advance if it isn't
>>the most idiomatic C++ code.
> 
>   In C++, assignments and initializations are different
>   concepts.
> 
>>int& b = a;  // reference variable or alias
> 
>   This is an initialization, not an assignment.

A pedantic difference that makes no difference to my argument.

I see that you ignored the later assignment:

b = 2;

which also assigned to a. *That** is the fundamental point: b is certainly an
alias for a, and assigning to b assigns to a.

That's how aliases work in C++. That's how var parameters in Pascal work, and
out parameters in Ada. That is what it means to say that "b is an alias to a".

b is another name for the *variable* a, not just whatever value a happens to
hold now.

I say that assignment in Python is NOT an aliasing operation. Antoon claims I'm
wrong, and his evidence is:

a = []
b = a  # Antoon says this is an alias operation
b.append(1)
assert a == [1]


But that's not enough for the variable b to be an alias for the variable a.

Antoon is correct that a and b are two different names for the same list, but
the two variables are not aliases to each other because assignments to b do not
affect a, and vice versa.

A good test for aliasing is to take the source code and mechanically replace
every occurrence of the alias (in the same scope of course) with the original,
or vice versa, and see whether the meaning of the code changes.

In C++, apart from the initial binding:

int& b = a;

("initialisation") you could now randomly swap a for b or b for a and the
meaning of the code will not change.

But in Python, if we try the same trick, the code *does* change:

a = 1
b = a
b = 2

*is not* the same as:

a = 1
b = a
a = 2


(1) In Pascal, Ada, C++ etc using a reference variable (or var parameter, or
whatever terminology they use) makes the two names aliases to EACH OTHER, not
to the value they are bound to.

(2) In Python, Javascript, Ruby etc assignment can give you two names for the
same object, but the names do not alias each other.

The critical distinction here is whether the names refer to each other:

a <---> b

or whether they merely refer to the same value:

a ---> [ value ] <--- b


Python uses the second model. Var parameters in Pascal and references in C++ use
the first. Since the term "aliasing" is well-established for the first, using
it in Python *without making the difference clear* is wrong.


-- 
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: Aliasing [was Re: [Tutor] beginning to code]

[ROGER GRAYDON CHRISTMAN]

On Tue, Sep 26, 2017 12:00 PM, Steve D'Aprano 
wrote:
>
> a = 1
>> b = a
>> b = 2
>> 
>> a is not 2.
>
< snip >
int main () {
>   int a;
>   int& b = a;  // reference variable or alias
>
>   a = 1;
>   printf("a: %d, alias b: %d\n", a, b);
>   b = 2;
>   printf("a: %d, alias b: %d\n", a, b);
>   return 0;
>}
>
>
>And here is the output:
>
>
>a: 1, alias b: 1
>a: 2, alias b: 2
>
>
>So I stand by what I said: assignment in Python is NOT an alias operation. If
it
>were an alias operation, as you claim, then we could write this:
>
>a = 1
>b = a  # alias to a
>b = 2  # assigning to be is like assigning to a (as in the C++
>example)
>assert a == 2
>
>But Python is not like that, assignment is not an alias operation, and the
>assert will fail.
>

I think you are being a bit choosy in your analysis of the examples.
You essentially claim that "assignment is not an alias operation" by
assuming that some assignments are not an alias operations,
and then conclude that it is inconsistent for the rest to be.

Here is a discussion of the code in light of the claim that assignment
is an alias operation, meaning _all_ assignments are aliases,
and not just the ones you choose to prove your point.

a = 1 # 'a' is an alias to the value 1
b = a # 'b' is an alias to the value named by a, which is also an alias to 1
b = 2 # 'b' is now an alias to the value of 2, and no longer an alias to
'a' or 1

Your C++ counterexample is invalid, because, indeed, only the second
of the three assignments is an alias operation, and only because you
specifically declare variable b to be a reference variable.  You are not
really 'assigning' to b -- you are initializing the reference variable named
b..  

If we were to add an additional statement into both examples.

b = c

In Python, this would be another aliasing operation, causing b to
refer to the same thing as c refers to (assuming c has been assigned).

But in C++, that statement would be completely invalid -- once you
associate a reference to a reference variable, you cannot change
the binding.This further emphasizes that the statement "int  = a"
is not an assignment statement, which means it is rather irrelevant
to the semantics of assignment statements.

Roger Christman
Pennsylvania State University

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

Re: Call by binding [was Re: [Tutor] beginning to code]

[Marko Rauhamaa]

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: Grumpy-pants spoil-sport [was Re: [Tutor] beginning to code]

[Chris Angelico]

On Wed, Sep 27, 2017 at 5:24 AM, Grant Edwards
 wrote:
> On 2017-09-26, alister via Python-list  wrote:
>> On Tue, 26 Sep 2017 14:16:47 +, Grant Edwards wrote:
>>
>>> On 2017-09-26, Ned Batchelder  wrote:
 On 9/25/17 10:20 PM, Steve D'Aprano wrote:
> On Tue, 26 Sep 2017 02:54 am, Ned Batchelder wrote:
> [...]
>
>
>
 We've been asked nicely by the list mod to stop :)
>>>
>>> Perhaps we could agree on a subject line tag to be used in all threas
>>> arguing about what to call the Python argument passing scheme?  That way
>>> the other 99% of us could pre-emptively plonk it?
>>
>> so you are suggesting a system where we could reject by reference :-)
>
> That depends on what you mean by "reference".
>
> And what you mean by "mean".

Well, *obviously*, reference is the section of the library that you're
not allowed to borrow, and "mean" is the average of a set of numbers.

Which means that CPython is breaking the rules every time it returns a
"borrowed reference".

ChrisA
joke-taker-too-far
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Grumpy-pants spoil-sport [was Re: [Tutor] beginning to code]

[Grant Edwards]

On 2017-09-26, alister via Python-list  wrote:
> On Tue, 26 Sep 2017 14:16:47 +, Grant Edwards wrote:
>
>> On 2017-09-26, Ned Batchelder  wrote:
>>> On 9/25/17 10:20 PM, Steve D'Aprano wrote:
 On Tue, 26 Sep 2017 02:54 am, Ned Batchelder wrote:
 [...]



>>> We've been asked nicely by the list mod to stop :)
>> 
>> Perhaps we could agree on a subject line tag to be used in all threas
>> arguing about what to call the Python argument passing scheme?  That way
>> the other 99% of us could pre-emptively plonk it?
>
> so you are suggesting a system where we could reject by reference :-)

That depends on what you mean by "reference".

And what you mean by "mean".

-- 
Grant Edwards   grant.b.edwardsYow! It's some people
  at   inside the wall!  This is
  gmail.combetter than mopping!

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

Re: Grumpy-pants spoil-sport [was Re: [Tutor] beginning to code]

[Tim Chase]

On 2017-09-26 18:25, alister via Python-list wrote:
>>> We've been asked nicely by the list mod to stop :)  
>> 
>> Perhaps we could agree on a subject line tag to be used in all
>> threas arguing about what to call the Python argument passing
>> scheme?  That way the other 99% of us could pre-emptively plonk
>> it?  
> 
> so you are suggesting a system where we could reject by
> reference :-)

I think the suggestion is to bind a name to the thread and reject by
name-binding.

Grinning-ducking-and-running'ly yers...

-tkc


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

Re: Grumpy-pants spoil-sport [was Re: [Tutor] beginning to code]

[Chris Angelico]

On Wed, Sep 27, 2017 at 4:25 AM, alister via Python-list
 wrote:
> On Tue, 26 Sep 2017 14:16:47 +, Grant Edwards wrote:
>
>> On 2017-09-26, Ned Batchelder  wrote:
>>> On 9/25/17 10:20 PM, Steve D'Aprano wrote:
 On Tue, 26 Sep 2017 02:54 am, Ned Batchelder wrote:
 [...]



>>> We've been asked nicely by the list mod to stop :)
>>
>> Perhaps we could agree on a subject line tag to be used in all threas
>> arguing about what to call the Python argument passing scheme?  That way
>> the other 99% of us could pre-emptively plonk it?
>
> so you are suggesting a system where we could reject by reference :-)

No, you don't actually reject them. You allow them to be posted, but
you simply skip over the ones you don't like. You pass them by.

That's the REAL meaning of "pass by reference".

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Grumpy-pants spoil-sport [was Re: [Tutor] beginning to code]

[alister via Python-list]

On Tue, 26 Sep 2017 14:16:47 +, Grant Edwards wrote:

> On 2017-09-26, Ned Batchelder  wrote:
>> On 9/25/17 10:20 PM, Steve D'Aprano wrote:
>>> On Tue, 26 Sep 2017 02:54 am, Ned Batchelder wrote:
>>> [...]
>>>
>>>
>>>
>> We've been asked nicely by the list mod to stop :)
> 
> Perhaps we could agree on a subject line tag to be used in all threas
> arguing about what to call the Python argument passing scheme?  That way
> the other 99% of us could pre-emptively plonk it?

so you are suggesting a system where we could reject by reference :-)



-- 
hard, adj.:
The quality of your own data; also how it is to believe those
of other people.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Aliasing [was Re: [Tutor] beginning to code]

[Antoon Pardon]

On 26-09-17 14:28, Steve D'Aprano wrote:
> On Tue, 26 Sep 2017 03:26 am, Antoon Pardon wrote:
> 
>> Sorry, what he wrote contradicts that. Maybe he was just really confused
>> at that moment, but it still needed correction. If the assignment is
>> an alias operator then after the statements
>>
>> a = 1
>> b = a
>> b = 2
>>
>> a is not 2.
> 
> How do you get that conclusion? I think you are mistaken.
> 
> If assignment were an alias operation, then a would be 2, because b is an 
> alias
> to a. That's how var parameters in Pascal work, and out parameters in Ada, and
> both are described as aliasing.

They work like that because the assignment in Pascal is *not* an alias 
operation.

> Its also how reference variables ("aliases") in C++ work.
> 
> https://www.tutorialspoint.com/cplusplus/cpp_references.htm
> 
> https://stackoverflow.com/a/17025902
> 
> 
> Here's some C++ code that demonstrates it. Apologies in advance if it isn't 
> the
> most idiomatic C++ code.

No that C++ code doesn't demonstrate your assertion. You ignore the fact that
only the 7th line is an alias operation, all the assignments (later) are copy
operations.

> #include 
> #include
> using namespace std;
> 
> int main () {
>int a;
>int& b = a;  // reference variable or alias
> 
>a = 1;
>printf("a: %d, alias b: %d\n", a, b);
>b = 2;
>printf("a: %d, alias b: %d\n", a, b);
>return 0;
> }

Because similarity of notation may be causing some confusion, I'll introduce two
new symbols.

:= This is the symbol I use for an assignment as copy operation, like Pascal.
<- This is the symbol I use for an assignment as alias operation.

So if the assignment is an alias operation, the code I was making an assertion
about, rewritten using these symbols would be:

a <- 1
b <- a
b <- 2

The code you use in support of your assertion instead behaves more like.

b <- a   # The order of the first two statements
a := 1   # doesn't matter, my criticism doesn't depend on that.
b := 2

If you want to make a statement about the effects of assignemt as an
alias operation, you will have to support that with code that actually
behaves like an alias operation each time an assignment is made. Not
code like your C++ example which only executes one alias operation and
where the rest of the assignments are copy operations.

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

Re: Grumpy-pants spoil-sport [was Re: [Tutor] beginning to code]

[Tim Golden]

On 26/09/2017 15:16, Grant Edwards wrote:

On 2017-09-26, Ned Batchelder  wrote:

On 9/25/17 10:20 PM, Steve D'Aprano wrote:

On Tue, 26 Sep 2017 02:54 am, Ned Batchelder wrote:
[...]




We've been asked nicely by the list mod to stop :)


Perhaps we could agree on a subject line tag to be used in all threas
arguing about what to call the Python argument passing scheme?  That
way the other 99% of us could pre-emptively plonk it?


+100

:)

TJG

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

Re: Grumpy-pants spoil-sport [was Re: [Tutor] beginning to code]

[Grant Edwards]

On 2017-09-26, Ned Batchelder  wrote:
> On 9/25/17 10:20 PM, Steve D'Aprano wrote:
>> On Tue, 26 Sep 2017 02:54 am, Ned Batchelder wrote:
>> [...]
>>
>>
>
> We've been asked nicely by the list mod to stop :)

Perhaps we could agree on a subject line tag to be used in all threas
arguing about what to call the Python argument passing scheme?  That
way the other 99% of us could pre-emptively plonk it?

-- 
Grant Edwards   grant.b.edwardsYow! My BIOLOGICAL ALARM
  at   CLOCK just went off ... It
  gmail.comhas noiseless DOZE FUNCTION
   and full kitchen!!

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

Aliasing [was Re: [Tutor] beginning to code]

[Steve D'Aprano]

On Tue, 26 Sep 2017 03:26 am, Antoon Pardon wrote:

>>> I'm not sure that Steve knows how it works. When he denies that the
>>> assignment is an alias operation in Python that casts an important doubt.
>> 
>> I can assure you that Steve knows how it works. Again, the disagreement is
>> almost certainly over the semantics of the word "alias."
> 
> Sorry, what he wrote contradicts that. Maybe he was just really confused
> at that moment, but it still needed correction. If the assignment is
> an alias operator then after the statements
> 
> a = 1
> b = a
> b = 2
> 
> a is not 2.

How do you get that conclusion? I think you are mistaken.

If assignment were an alias operation, then a would be 2, because b is an alias
to a. That's how var parameters in Pascal work, and out parameters in Ada, and
both are described as aliasing.

Its also how reference variables ("aliases") in C++ work.

https://www.tutorialspoint.com/cplusplus/cpp_references.htm

https://stackoverflow.com/a/17025902


Here's some C++ code that demonstrates it. Apologies in advance if it isn't the
most idiomatic C++ code.

#include 
#include
using namespace std;

int main () {
   int a;
   int& b = a;  // reference variable or alias

   a = 1;
   printf("a: %d, alias b: %d\n", a, b);
   b = 2;
   printf("a: %d, alias b: %d\n", a, b);
   return 0;
}


And here is the output:


a: 1, alias b: 1
a: 2, alias b: 2


So I stand by what I said: assignment in Python is NOT an alias operation. If it
were an alias operation, as you claim, then we could write this:

a = 1
b = a  # alias to a
b = 2  # assigning to be is like assigning to a (as in the C++ example)
assert a == 2

But Python is not like that, assignment is not an alias operation, and the
assert will fail.




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

[Rhodri James]

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]

[Rhodri James]

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]

[Marko Rauhamaa]

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: [Tutor] beginning to code

[Antoon Pardon]

Op 25-09-17 om 21:44 schreef Ned Batchelder:
>
> Wikipedia has the right definition of call by reference
> (https://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_reference):
>
>    /Call by reference/ (also referred to as /pass by reference/) is an
>    evaluation strategy where a function receives an implicit reference
>     to
>    a variable used as argument, rather than a copy of its value. This
>    typically means that the function can modify (i.e. assign to
>    )
>    the variable used as argument—something that will be seen by its
> caller.
>
> The key idea here is that it is a reference to a *variable* that is
> passed, not a reference to a value.  Python has no references to
> variables, so it cannot support call by reference.   Because Python
> passes references to values, it is easy to call it "call by
> reference," but that is not what the term means.
>
> The Wikipedia definition unfortunately includes "rather than a copy of
> its value," as if those are the only two options (a common
> misunderstanding).
>
> Elsewhere in this thread, someone asserted that to be call by
> reference, you have to be able to write a swap(x,y) function.  True
> call-by-reference would make this possible.  Python cannot do it.

I can write a swap function for lists in python. Can I now conclude
that lists are passed by reference?

-- 
Antoon Pardon.

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

Re: [Tutor] beginning to code

[Gregory Ewing]

Antoon Pardon wrote:

It also says: This typically means that the function can modify the variable
used as argument, something Python can do that.


No, it can't. It can modify the *object* bound to the variable,
but *not* the variable itself.

If you think it can, then you're misunderstanding what is
meant by "variable" in this context.

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

[Gregory Ewing]

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: Grumpy-pants spoil-sport [was Re: [Tutor] beginning to code]

[Ned Batchelder]

On 9/25/17 10:20 PM, Steve D'Aprano wrote:

On Tue, 26 Sep 2017 02:54 am, Ned Batchelder wrote:
[...]




We've been asked nicely by the list mod to stop :)

--Ned.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Call by binding [was Re: [Tutor] beginning to code]

[Bill]

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]

[Bill]

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: Grumpy-pants spoil-sport [was Re: [Tutor] beginning to code]

[Steve D'Aprano]

On Tue, 26 Sep 2017 02:54 am, Ned Batchelder wrote:
[...]

Heh, its hard to avoid getting sucked into the sinkhole of definitional debates,
isn't it? :-)

[...]
> But in this line:
> 
>  x = 2 + 2
> 
> You can say,
> 
>  the value of x is 4

If we're talking about the highest level abstraction level, namely the Python
code, that would be the right answer. Provided that we understand that as
short-hand for:

>  the value of x is an int object with a value of 4

However:

> or,
> 
>  the value of x is a reference to an int object with a value of 4,

while that's true from a certain perspective, it's not the high-level Python
perspective. Its that of the implementation.

It's a perfectly valid perspective, and its often not just useful but (almost)
necessary. Some behaviours of Python are difficult to understand unless we dip
down an abstraction level and look at the implementation.


> and in some ways, each of those is a correct statement. They are
> different perspectives on the same complicated abstract relationships
> inside your program.  Most of the disagreements in this thread stem from
> someone picking one of those three statements and insisting that it is
> *the* right statement, or from differing interpretations of words like
> value, reference, pointer, alias, etc.

This topic has been discussed a lot over the last few weeks/months, and that's
something I've  also said: it is useful if not necessary to discuss different
levels of abstractions, but one needs to be clear when you are doing so.

We all take verbal short-cuts from time to time, and I'll often use language
like

"evaluating the expression returns a reference (a pointer) to the object ..."

(language which Marko would, I think, agree with) if I feel it brings insight to
the question being discussed. From a purely pedantic point of view, I'll say
I'm slightly naughty to do so, because I'm crossing abstractions without being
explicit about it. "Explicit is better than implicit."

So we all do it. I have no problem with people taking short-cuts or crossing
abstractions and even mixing explanations from different levels, provided it
brings insight and clarity to the question rather than confusion.

Its better to be explicit about it when you do so ("under the hood, the
interpreter uses a pointer to the object...") but we're all only human and
sometimes we make implicit assumptions.

But I do have to wonder about people who insist on keeping an inflexible,
single-minded point of view even in the face of confusion. To use your analogy
from below, it is as if they were absolutely, categorically denying that
pressing the gas pedal (accelerator pedal) has anything to do with the car
moving, because its the engine that makes it move, and that's the only right
answer.

Its fine to discuss what happens in different abstraction layers, but be clear
about it when you do.


> Software gets complicated because it involves multiple levels of
> abstraction layered on top of each other.  We might as well be arguing
> like this:
> 
>  A: "The gas pedal makes the car go"
> 
>  B: "Nonsense! The gas pedal supplies fuel to the engine, it's the 
> engine that makes the car go"
[snip]

Indeed. 


-- 
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: Grumpy-pants spoil-sport [was Re: [Tutor] beginning to code]

[Antoon Pardon]

On 25-09-17 18:29, Steve D'Aprano wrote:

> 
> Regardless of whether I'm using Python, Swift, Java, C, Pascal or Scheme, if I
> write something like:
> 
> x = Parrot(name="Polly")
> 
> (using Python syntax for simplicity) and somebody tries to tell me that the
> value of x is anything but a Parrot instance named "Polly", I have no time for
> that sort of nonsense. They might as well tell me that I'm typing this 
> response
> on an elephant.

And if you write it like that, implying that the assignment semantics is the
same for all these languages, I'm not surprises people get confused.

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

Re: [Tutor] beginning to code

[Antoon Pardon]

On 25-09-17 21:44, Ned Batchelder wrote:
> On 9/25/17 5:32 AM, Antoon Pardon wrote:
>> Can you explain, what you mean by "Pass-By-Reference" as far a I understand,
>> pass by reference means that the parameter of the function becomes an alias
>> of the argument, so that if the entity is mutated through one name that
>> mutation is visible through the other name.
>>
>>> function(x, y)  # allowed
>>> function(namespace.x, module.y)  # allowed
>>> function(x + 1, 2)  # FORBIDDEN: can't pass expressions or constants
>> Pass by reference, doesn't imply the above is forbidden. A language can
>> define, that the "x + 1" will produce an new entity and that a reference
>> to that entity will be passed.
>>
> 
> Wikipedia has the right definition of call by reference 
> (https://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_reference):
> 
>/Call by reference/ (also referred to as /pass by reference/) is an
>evaluation strategy where a function receives an implicit reference
> to
>a variable used as argument, rather than a copy of its value. This
>typically means that the function can modify (i.e. assign to
>)
>the variable used as argument—something that will be seen by its caller.
> 
> The key idea here is that it is a reference to a *variable* that is passed, 
> not a reference to a value.  Python has no references to variables, so it 
> cannot support call by reference.   Because Python passes references to 
> values, it is easy to call it
> "call by reference," but that is not what the term means.

And what would such a reference to a variable be exactly? If you mean the name,
languages like Pascal don't have that either. If you mean a reference to
an object/entity, Python has those.

It also says: This typically means that the function can modify the variable
used as argument, something Python can do that.

> 
> The Wikipedia definition unfortunately includes "rather than a copy of its 
> value," as if those are the only two options (a common misunderstanding).
> 
> Elsewhere in this thread, someone asserted that to be call by reference, you 
> have to be able to write a swap(x,y) function.  True call-by-reference would 
> make this possible.  Python cannot do it.

That is because assignments in python don't make modifications to what
the name refers to. If you can't modify the object because the semantics
of the assignment don't do that, you can't use the impossibility of
a swap for inferring that we don't have true call by reference.

You can't write a swap in smalltalk either but the smalltalk documentation
specifies that arguments are call by reference.

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

Re: Call by binding [was Re: [Tutor] beginning to code]

[Marko Rauhamaa]

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: [Tutor] beginning to code

[Chris Angelico]

On Tue, Sep 26, 2017 at 5:51 AM, Stefan Ram  wrote:
> Ned Batchelder  writes:
>>Wikipedia has the right definition of call by reference
>
>   Assertions can be right or wrong.
>
>   Definitions cannot be right or wrong.

You have made two assertions. One of them is right. The other is wrong. :-)

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

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Call by binding [was Re: [Tutor] beginning to code]

[Marko Rauhamaa]

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]

[Chris Angelico]

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]

[Marko Rauhamaa]

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]

[Chris Angelico]

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]

[Antoon Pardon]

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]

[Rhodri James]

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]

[ROGER GRAYDON CHRISTMAN]

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]

[Antoon Pardon]

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]

[Chris Angelico]

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: Grumpy-pants spoil-sport [was Re: [Tutor] beginning to code]

[Chris Angelico]

On Tue, Sep 26, 2017 at 2:52 AM, Tim Chase
 wrote:
> On 2017-09-26 02:29, Steve D'Aprano wrote:
>> x = Parrot(name="Polly")
>>
>> (using Python syntax for simplicity) and somebody tries to tell me
>> that the value of x is anything but a Parrot instance named "Polly",
>
> So this is a Polly-morphic constructor?

Steve actually said:

> Regardless of whether I'm using Python, Swift, Java, C, Pascal or Scheme, if I
> write something like:

So it's actually Polly-glot.

ChrisA
-- 
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 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: [Tutor] beginning to code

[Antoon Pardon]

On 25-09-17 15:37, Ned Batchelder wrote:
> On 9/25/17 9:15 AM, Antoon Pardon wrote:
>> Op 25-09-17 om 14:53 schreef Ned Batchelder:
>>> On 9/25/17 8:24 AM, Steve D'Aprano wrote:
 On Mon, 25 Sep 2017 08:05 pm, Antoon Pardon wrote:

> Pass by reference doesn't imply being able to
> write a swap function.
 Really. Do you have a counter-example?


> A swap function as possible in pascal requires two conditions.
>
> 1) Pass by reference
> 2) Copy-over assignment.
 I don't know what you think "copy-over assignment" means, but none of
 DuckDuckGo, Google, Bing or Yahoo finds that term except in your post.




>>> Would we be able to end these interminable debates if we just agree
>>> that we all know how it works, and it isn't important to come up with
>>> a simple name for what it is?
>> I'm not sure that Steve knows how it works. When he denies that the 
>> assignment is
>> an alias operation in Python that casts an important doubt.
> 
> I can assure you that Steve knows how it works. Again, the disagreement is 
> almost certainly over the semantics of the word "alias."

Sorry, what he wrote contradicts that. Maybe he was just really confused
at that moment, but it still needed correction. If the assignment is
an alias operator then after the statements

a = 1
b = a
b = 2

a is not 2. He is not using the assignment as an alias operation in
that last assignment but as a copy operation that will overwrite the
value that b refers to.

>>> It seems clear to me that "value" and "reference" are wildly vague
>>> terms, used slightly differently by each language, and by different
>>> people even in the same language if they have different perspectives.
>> Well in that case and considering your remark above, maybe the residents
>> shouldn't be so eager to deny to newbees that python has call by reference.
> 
> You're still trying to get people to agree to a label like "call by 
> reference."  This is where the disagreement comes from.
> 
No I'm trying to make them stop disagreeing to a label like call by reference.
They may personnaly prefer an other label but this is not about them, this
is about the newbe. And if someone can explain the newbe what is going on
in terms of "call by reference", something the newbe understands, then that
is what is important and those that prefer an other lable should at that
moment not interfere and possibly cause confusion.

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

Re: Call by binding [was Re: [Tutor] beginning to code]

[Antoon Pardon]

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: Grumpy-pants spoil-sport [was Re: [Tutor] beginning to code]

[Tim Chase]

On 2017-09-26 02:29, Steve D'Aprano wrote:
> x = Parrot(name="Polly")
> 
> (using Python syntax for simplicity) and somebody tries to tell me
> that the value of x is anything but a Parrot instance named "Polly",

So this is a Polly-morphic constructor?

-tkc


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

calling __del__ [was Re: [Tutor] beginning to code]

[Steve D'Aprano]

On Sun, 24 Sep 2017 09:13 am, Bill wrote:

[context snipped for brevity]
> I agree (I was a bit hasty in my choice of words); but if they didn't
> "have" these references, it would be difficult, though not impossible,
> to refer to them.   Also keep in mind that the garbage collector keeps
> track, generally, of how many there are for each object!   So from the
> gc's point of view, objects (definitely) "have" references.

Unfortunately there's some ambiguity in the English word "have". Webster's
dictionary (1913) lists at least twelve distinct meanings. WordNet lists
nineteen.

If we consider "have" in the sense of possession, then objects don't have
references. If they did, you could ask an object what names they were known as,
and they could tell you:

# this doesn't work!
a = 99
b = c = a
a.names()
# returns ['a', 'b', 'c']


You can't do that in Python.

But in another sense, ironically one which isn't listed by either Webster's or
WordNet, objects do have references. The closest meaning I see is:

7: have a personal or business relationship with someone; "have
   a postdoc"; "have an assistant"; "have a lover"

Its not a *personal* or *business* relationship, but there is a relationship
between the reference and the object.


> Next, what will Egg.__del__() do? : )

For the record, you shouldn't call dunder ("Double UNDERscore") methods directly
unless you know what you're doing. You should consider them for Python's use
only, unless explicitly told differently.

Calling __del__ directly is *especially* fraught with problems. It does not
delete the object. It just runs the destructor, but leaving the object alive
but in a potentially unusable state.


-- 
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: Grumpy-pants spoil-sport [was Re: [Tutor] beginning to code]

[Ned Batchelder]

On 9/25/17 12:29 PM, Steve D'Aprano wrote:

Regardless of whether I'm using Python, Swift, Java, C, Pascal or Scheme, if I
write something like:

x = Parrot(name="Polly")

(using Python syntax for simplicity) and somebody tries to tell me that the
value of x is anything but a Parrot instance named "Polly", I have no time for
that sort of nonsense. They might as well tell me that I'm typing this response
on an elephant.


But in this line:

    x = 2 + 2

You can say,

    the value of x is 4

or,

    the value of x is an int object with a value of 4

or,

    the value of x is a reference to an int object with a value of 4,

and in some ways, each of those is a correct statement. They are 
different perspectives on the same complicated abstract relationships 
inside your program.  Most of the disagreements in this thread stem from 
someone picking one of those three statements and insisting that it is 
*the* right statement, or from differing interpretations of words like 
value, reference, pointer, alias, etc.


Software gets complicated because it involves multiple levels of 
abstraction layered on top of each other.  We might as well be arguing 
like this:


    A: "The gas pedal makes the car go"

    B: "Nonsense! The gas pedal supplies fuel to the engine, it's the 
engine that makes the car go"


    C: "None of you know what you are talking about! The engine merely 
turns the axle. It's the wheels that make the car go!"


    D: "The wheels only work because of the friction between rubber and 
asphalt!"


etc etc etc.

--Ned.
--
https://mail.python.org/mailman/listinfo/python-list

Grumpy-pants spoil-sport [was Re: [Tutor] beginning to code]

[Steve D'Aprano]

On Mon, 25 Sep 2017 10:53 pm, Ned Batchelder wrote:

> Would we be able to end these interminable debates if we just agree that
> we all know how it works, 

If only that were true. Not everyone understands Python semantics (or for that
matter, Java/Swift/language of your choice) and I still come across people
confused by the pass by value/reference false dichotomy and which applies to
.


> and it isn't important to come up with a 
> simple name for what it is?

Isn't it?

I find it really difficult to understand people when the meanings they apply to
words are not the same as the ones I use.

Or perhaps I should say:

I disintegrate it really snooze to pyramid running when the ribbons they
apply to sandwiches are not the same as the sleep I use.


*wink*


> It seems clear to me that "value" and 
> "reference" are wildly vague terms, used slightly differently by each
> language, and by different people even in the same language if they have
> different perspectives.

Honestly Ned, I don't think that's right. I think you're being awfully
accommodating to what I see as some really egregious misuse of language. I
don't think that "value", in particular, is a vague term.

(I might be persuaded to accept that "reference" has some ambiguity.)

Regardless of whether I'm using Python, Swift, Java, C, Pascal or Scheme, if I
write something like:

x = Parrot(name="Polly")

(using Python syntax for simplicity) and somebody tries to tell me that the
value of x is anything but a Parrot instance named "Polly", I have no time for
that sort of nonsense. They might as well tell me that I'm typing this response
on an elephant.


> Can't we just stop? :)

You take all the fun out of being right on the internet.



-- 
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: [Tutor] beginning to code

[Ned Batchelder]

On 9/25/17 9:15 AM, Antoon Pardon wrote:

Op 25-09-17 om 14:53 schreef Ned Batchelder:

On 9/25/17 8:24 AM, Steve D'Aprano wrote:

On Mon, 25 Sep 2017 08:05 pm, Antoon Pardon wrote:


Pass by reference doesn't imply being able to
write a swap function.

Really. Do you have a counter-example?



A swap function as possible in pascal requires two conditions.

1) Pass by reference
2) Copy-over assignment.

I don't know what you think "copy-over assignment" means, but none of
DuckDuckGo, Google, Bing or Yahoo finds that term except in your post.





Would we be able to end these interminable debates if we just agree
that we all know how it works, and it isn't important to come up with
a simple name for what it is?

I'm not sure that Steve knows how it works. When he denies that the assignment 
is
an alias operation in Python that casts an important doubt.


I can assure you that Steve knows how it works. Again, the disagreement 
is almost certainly over the semantics of the word "alias."



It seems clear to me that "value" and "reference" are wildly vague
terms, used slightly differently by each language, and by different
people even in the same language if they have different perspectives.

Well in that case and considering your remark above, maybe the residents
shouldn't be so eager to deny to newbees that python has call by reference.


You're still trying to get people to agree to a label like "call by 
reference."  This is where the disagreement comes from.


--Ned.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Call by binding [was Re: [Tutor] beginning to code]

[Marko Rauhamaa]

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]

[Marko Rauhamaa]

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]

[Chris Angelico]

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]

[Antoon Pardon]

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]

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

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: [Tutor] beginning to code

[Antoon Pardon]

Op 25-09-17 om 14:53 schreef Ned Batchelder:
> On 9/25/17 8:24 AM, Steve D'Aprano wrote:
>> On Mon, 25 Sep 2017 08:05 pm, Antoon Pardon wrote:
>>
>>> Pass by reference doesn't imply being able to
>>> write a swap function.
>> Really. Do you have a counter-example?
>>
>>
>>> A swap function as possible in pascal requires two conditions.
>>>
>>> 1) Pass by reference
>>> 2) Copy-over assignment.
>> I don't know what you think "copy-over assignment" means, but none of
>> DuckDuckGo, Google, Bing or Yahoo finds that term except in your post.
>>
>>
>>
>>
>
> Would we be able to end these interminable debates if we just agree
> that we all know how it works, and it isn't important to come up with
> a simple name for what it is?

I'm not sure that Steve knows how it works. When he denies that the assignment 
is
an alias operation in Python that casts an important doubt.

> It seems clear to me that "value" and "reference" are wildly vague
> terms, used slightly differently by each language, and by different
> people even in the same language if they have different perspectives.

Well in that case and considering your remark above, maybe the residents
shouldn't be so eager to deny to newbees that python has call by reference.

IMO the problem people have with python isn't because they may think
python has call by reference but because they don't fully understand
how the assignment works.

The conclusion they jump to, that call by reference implies being able
to write a swap function, depends on the assignment semantics in a
language like Pascal.

Yet that it is the assignment semantics of python and not the argument
passing semantics that prohibit the writing of a swap function in Python
is rarely made clear.

-- 
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:
> 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: [Tutor] beginning to code

[Ned Batchelder]

On 9/25/17 8:24 AM, Steve D'Aprano wrote:

On Mon, 25 Sep 2017 08:05 pm, Antoon Pardon wrote:


Pass by reference doesn't imply being able to
write a swap function.

Really. Do you have a counter-example?



A swap function as possible in pascal requires two conditions.

1) Pass by reference
2) Copy-over assignment.

I don't know what you think "copy-over assignment" means, but none of
DuckDuckGo, Google, Bing or Yahoo finds that term except in your post.






Would we be able to end these interminable debates if we just agree that 
we all know how it works, and it isn't important to come up with a 
simple name for what it is? It seems clear to me that "value" and 
"reference" are wildly vague terms, used slightly differently by each 
language, and by different people even in the same language if they have 
different perspectives.


Can't we just stop? :)

--Ned.
--
https://mail.python.org/mailman/listinfo/python-list

Re: [Tutor] beginning to code

[Antoon Pardon]

Op 25-09-17 om 14:24 schreef Steve D'Aprano:
> On Mon, 25 Sep 2017 08:05 pm, Antoon Pardon wrote:
>
>> Pass by reference doesn't imply being able to
>> write a swap function.
> Really. Do you have a counter-example?

Python, smalltalk, scheme.

>
>
>> A swap function as possible in pascal requires two conditions.
>>
>> 1) Pass by reference
>> 2) Copy-over assignment.
> I don't know what you think "copy-over assignment" means, but none of
> DuckDuckGo, Google, Bing or Yahoo finds that term except in your post.

I think it was clear enough that I was talking about the assignment
semantics like in Pascal, where when you assign to a variable the
value in the entity refered to, is overwritten by a new value.

In contrast with assignments in Python, smalltalk, scheme where
the assignment binds the name/variable to a new entity.

-- 
Antoon Pardon. 

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

Re: [Tutor] beginning to code

[Steve D'Aprano]

On Mon, 25 Sep 2017 08:05 pm, Antoon Pardon wrote:

> Pass by reference doesn't imply being able to
> write a swap function.

Really. Do you have a counter-example?


> A swap function as possible in pascal requires two conditions.
> 
> 1) Pass by reference
> 2) Copy-over assignment.

I don't know what you think "copy-over assignment" means, but none of
DuckDuckGo, Google, Bing or Yahoo finds that term except in your post.




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

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

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]

[Antoon Pardon]

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]

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

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]

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

-- 
Antoon Pardon.

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

Re: [Tutor] beginning to code

[Antoon Pardon]

Op 22-09-17 om 15:30 schreef Steve D'Aprano:
> On Fri, 22 Sep 2017 10:27 pm, Marko Rauhamaa wrote:
>
>> r...@zedat.fu-berlin.de (Stefan Ram):
>>
>>> Marko Rauhamaa  writes:
 swap(slot_ref(locals(), "x"), slot_ref(locals(), "y"))
>>>   You need to be able to write the call as
>>>
>>> swap( x, y )
>> Why?
> Because that's the whole point of the exercise.
>
> The exercise isn't to demonstrate how to swap two variables. In Python, that's
> easy:
>
> a, b = b, a
>
> The exercise is to demonstrate pass by reference semantics. That requires
> demonstrating the same semantics as the Pascal swap procedure:

No it doesn't. Pass by reference doesn't imply being able to
write a swap function. A swap function as possible in pascal
requires two conditions.

1) Pass by reference
2) Copy-over assignment.

Since python doesn't have the second, the fact that you can't
write a swap function doesn't imply you don't have pass by
reference.

>
> procedure swap(var a, var b):
>   begin
> tmp := a;
> a := b;
> b := tmp;
>   end;
>
> (ignoring the type declarations for brevity).
>
> Call by reference semantics enable you to call swap(x, y) to swap x and y in 
> the
> caller's scope. You don't call swap('x', 'y', scope_of_x, scope_of_y) or any
> other variant. That isn't call by reference semantics.

No it doesn't, not unless the assignment mutates by copying the value on the
right side over the variable on the left side. Your assertions about call
by reference only apply in a particular context, one where assignments mutate
the variable that is assigned to.

This is a point you continuously ignore.

-- 
Antoon Pardon.

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

Re: Call by binding [was Re: [Tutor] beginning to code]

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

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: [Tutor] beginning to code

[Antoon Pardon]

Op 24-09-17 om 04:13 schreef Steve D'Aprano:
>> and consider 
>> that something else has to happen as an alternative, and (2) understand
>> that in Python, objects don't have names, they have references (which
>> have names).  The rest could be "implementation dependent" (no?)
> No.
>
> There are many different alternatives for "something else", and while some of
> them may be behave the same in some circumstances, they do not behave the same
> in all circumstances. Any interpreter calling itself Python would be expected
> to match the behaviour of the reference implementation, CPython.
>
> For example, if I made "Pass-By-Reference Python" where all argument passing 
> was
> done by reference, my language would differ from real Python:

Can you explain, what you mean by "Pass-By-Reference" as far a I understand,
pass by reference means that the parameter of the function becomes an alias
of the argument, so that if the entity is mutated through one name that
mutation is visible through the other name.

> function(x, y)  # allowed
> function(namespace.x, module.y)  # allowed
> function(x + 1, 2)  # FORBIDDEN: can't pass expressions or constants

Pass by reference, doesn't imply the above is forbidden. A language can
define, that the "x + 1" will produce an new entity and that a reference
to that entity will be passed.

> Obviously that's not Python!
>
> On the other hand, "Pass-By-Name Python" would allow passing expressions and
> constants, but will differ in other ways.
>
> Assignment by reference would mean that name binding was an *alias* operation:

It is.

> module.y = 1
> x = module.y  # x is an alias for the name "module.y"
> x = 2  # binds 2 to module.y 

The comment in the above statement is wrong. You ignore the
fact that the assignment is an alias operation and so that
through the assignment x now becomes a new alias for the value 2.
Your statement should be:

x = 2  # x is now an alias for an object with value 2.


Your comment would have been true, if that assignment would have
been a copy-over assignment.

This is a confusion I see you make regularly. When making statements
about what effect reference parameters or an alias operation would
have, you at some point depend on the assignment being a copy-over
operation, as you did here.

The fact that assignment is an *alias* opertation is illustrated
by the fact that a mutation through one name, is visible through
the other 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 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]

[Gregory Ewing]

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]

[Gregory Ewing]

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]

[Steve D'Aprano]

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: [Tutor] beginning to code

[Steve D'Aprano]

On Sun, 24 Sep 2017 12:37 pm, Bill wrote:

>> For example, if I made "Pass-By-Reference Python" where all argument passing
>> was done by reference, my language would differ from real Python:
>>
>>
>> function(x, y)  # allowed
>> function(namespace.x, module.y)  # allowed
>> function(x + 1, 2)  # FORBIDDEN: can't pass expressions or constants
> 
> This would be okay as long as x + 1 evaluates to an object, no?

Not in Pascal, no.

(Pascal pre-dated objects, but by the 80s there were various forms of Pascal
with objects.)

Pascal requires that the actual argument passed to the var parameter be an
actual variable, not a constant or expression. Technically, it must be
a "L-value", something which can appear on the left hand side of an assignment
and therefore something that has an address.



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

[Steve D'Aprano]

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]

[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!

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

Re: Call by binding [was Re: [Tutor] beginning to code]

[bartc]

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]

[Steve D'Aprano]

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

Re: [Tutor] beginning to code

[Bill]

Steve D'Aprano wrote:

On Sun, 24 Sep 2017 08:18 am, Bill wrote:


All one has to do, I think, is consider (1) that passing objects by
"making copies" of them, would be prohibitively expensive


Swift passes certain values (but not others!) by value and makes a copy. That
includes many potentially large data types including strings, dictionaries and
arrays, but using copy-on-write so the data isn't physically copied until you
actually mutate it. From the Swift documentation:


 The description above refers to the “copying” of strings, arrays,
 and dictionaries. The behavior you see in your code will always
 be as if a copy took place. However, Swift only performs an actual
 copy behind the scenes when it is absolutely necessary to do so.
 Swift manages all value copying to ensure optimal performance, and
 you should not avoid assignment to try to preempt this optimization.

https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/ClassesAndStructures.html


So I maintain that one could design a language similar to Python except that
objects are assigned and passed by value, making copies only when actually
needed using copy-on-write. Swift is *almost* that language: the difference is
that Swift distinguishes between "structs" that are copied, and "objects" which
are not.



and consider
that something else has to happen as an alternative, and (2) understand
that in Python, objects don't have names, they have references (which
have names).  The rest could be "implementation dependent" (no?)

No.

There are many different alternatives for "something else", and while some of
them may be behave the same in some circumstances, they do not behave the same
in all circumstances. Any interpreter calling itself Python would be expected
to match the behaviour of the reference implementation, CPython.

For example, if I made "Pass-By-Reference Python" where all argument passing was
done by reference, my language would differ from real Python:


function(x, y)  # allowed
function(namespace.x, module.y)  # allowed
function(x + 1, 2)  # FORBIDDEN: can't pass expressions or constants


This would be okay as long as x + 1 evaluates to an object, no?




Obviously that's not Python!

On the other hand, "Pass-By-Name Python" would allow passing expressions and
constants, but will differ in other ways.

Assignment by reference would mean that name binding was an *alias* operation:


module.y = 1
x = module.y  # x is an alias for the name "module.y"
x = 2  # binds 2 to module.y
assert module.y == 2






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

Re: [Tutor] beginning to code

[Steve D'Aprano]

On Sun, 24 Sep 2017 08:18 am, Bill wrote:

> All one has to do, I think, is consider (1) that passing objects by
> "making copies" of them, would be prohibitively expensive 


Swift passes certain values (but not others!) by value and makes a copy. That
includes many potentially large data types including strings, dictionaries and
arrays, but using copy-on-write so the data isn't physically copied until you
actually mutate it. From the Swift documentation:


The description above refers to the “copying” of strings, arrays,
and dictionaries. The behavior you see in your code will always
be as if a copy took place. However, Swift only performs an actual
copy behind the scenes when it is absolutely necessary to do so.
Swift manages all value copying to ensure optimal performance, and
you should not avoid assignment to try to preempt this optimization.

https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/ClassesAndStructures.html


So I maintain that one could design a language similar to Python except that
objects are assigned and passed by value, making copies only when actually
needed using copy-on-write. Swift is *almost* that language: the difference is
that Swift distinguishes between "structs" that are copied, and "objects" which
are not.


> and consider 
> that something else has to happen as an alternative, and (2) understand
> that in Python, objects don't have names, they have references (which
> have names).  The rest could be "implementation dependent" (no?)

No.

There are many different alternatives for "something else", and while some of
them may be behave the same in some circumstances, they do not behave the same
in all circumstances. Any interpreter calling itself Python would be expected
to match the behaviour of the reference implementation, CPython.

For example, if I made "Pass-By-Reference Python" where all argument passing was
done by reference, my language would differ from real Python:


function(x, y)  # allowed
function(namespace.x, module.y)  # allowed
function(x + 1, 2)  # FORBIDDEN: can't pass expressions or constants


Obviously that's not Python!

On the other hand, "Pass-By-Name Python" would allow passing expressions and
constants, but will differ in other ways.

Assignment by reference would mean that name binding was an *alias* operation:


module.y = 1
x = module.y  # x is an alias for the name "module.y"
x = 2  # binds 2 to module.y
assert module.y == 2




-- 
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: [Tutor] beginning to code

[Steve D'Aprano]

On Sun, 24 Sep 2017 07:03 am, ROGER GRAYDON CHRISTMAN wrote:

> I usually do not encourage people to optimize correctness out of their code.


+1 quote of the week :-)




-- 
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: [Tutor] beginning to code

[Bill]

Chris Angelico wrote:

On Sun, Sep 24, 2017 at 8:18 AM, Bill  wrote:

Stephan Houben wrote:

Op 2017-09-23, Rick Johnson schreef :

These pissing contests over how values are passed in Python
are totally irrelevant. What does it matter? Nothing will be
gained or lost by arguing over which is true, or not. Unless
the distinction is preventing you from doing something that
you'd like to do, or unless you want to argue that one
"value passing method" would bring X, Y or Z benefits over
the other, what does it matter?

Amen.


All one has to do, I think, is consider (1) that passing objects by "making
copies" of them, would be prohibitively expensive and consider that
something else has to happen as an alternative, and (2) understand that in
Python, objects don't have names, they have references (which have names).
The rest could be "implementation dependent" (no?)   To be amusing, how did
the chicken pass an egg to the_other_side_of_the_road(e)?  Could the egg get
crushed (stay tuned)?

Actually they don't "have" references in any real sense of possession.
I agree (I was a bit hasty in my choice of words); but if they didn't 
"have" these references, it would be difficult, though not impossible, 
to refer to them.   Also keep in mind that the garbage collector keeps 
track, generally, of how many there are for each object!   So from the 
gc's point of view, objects (definitely) "have" references.  Next, 
what will Egg.__del__() do? : )





An object "has" things like its type, its attributes, etc etc; if you
have a reference to an object, you can query it for its type. But you
can't ask an object if there's a reference to it over here or there.
(Yes, I know that sys.getrefcount exists in CPython, but this isn't
part of the language's definition. Also, even that is just a counter -
you can't find specific references.) An object may have a reference to
other objects (eg a list's contents), but it's a one-way thing -
there's no way to find all the references to this object.

So more accurate would be to say that objects don't have names, but
names refer to objects. When you assign to a simple name, you cause
that name to refer to the object you gave it.

ChrisA


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

Re: [Tutor] beginning to code

[Bill]

Stephan Houben wrote:

Op 2017-09-23, Rick Johnson schreef :

These pissing contests over how values are passed in Python
are totally irrelevant. What does it matter? Nothing will be
gained or lost by arguing over which is true, or not. Unless
the distinction is preventing you from doing something that
you'd like to do, or unless you want to argue that one
"value passing method" would bring X, Y or Z benefits over
the other, what does it matter?

Amen.



All one has to do, I think, is consider (1) that passing objects by 
"making copies" of them, would be prohibitively expensive and consider 
that something else has to happen as an alternative, and (2) understand 
that in Python, objects don't have names, they have references (which 
have names).  The rest could be "implementation dependent" (no?)   To be 
amusing, how did the chicken pass an egg to 
the_other_side_of_the_road(e)?  Could the egg get crushed (stay tuned)?


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

Re: [Tutor] beginning to code

[ROGER GRAYDON CHRISTMAN]

On Fri, Sep 22, 2017 12:03 PM, Dennis Lee Bier  wrote:>
On Fri, 22 Sep 2017 23:30:34 +1000, Steve D'Aprano
>
 declaimed the following:
>

>The exercise is to demonstrate pass by reference semantics. That requires
>
>demonstrating the same semantics as the Pascal swap procedure:
>
>
>
>procedure swap(var a, var b):
>
>  begin
>
>tmp := a;
>
>a := b;
>
>b := tmp;
>
>  end;
>
>
>
>(ignoring the type declarations for brevity).
>
>
>
Or FORTRAN (since call-by-reference has been the standard in that
>
language from the start -- no special keywords needed to enable reference
>
semantics)... It's been 20 years, and I'm using an F90 text, so this is
>
going to be less than perfect:
>
subroutine iswap(a, b)
integer :: a
>
integer :: b
>
a = IEOR(a, b)
>
b = IEOR(a, b)
>
a = IEOR(a, b)
>
return
>
end
>
>{That's a bitwise exclusive OR; no temp storage needed}
>
> a = 123
>
> b = 321
>
> a = a ^ b
>
> a
>
314
>
> b = a ^ b
>
> b
>
123
>
> a = a ^ b
>
> a
>
321
>
>
>


And then along comes someone who asks for
to swap array elements a[I] and a[j], where I and j
just happen to be equal.You don't preserve the
values, as would be anticipated, but instead clear
the argument(s) to zero.

Saving one temp storage is a very tiny gain for the potential cost
of a program malfunction.   And if you go so far as to bring in 
a compiled language like Fortran into the mix, where the
'temp storage' is just a machine register, and not RAM,
you really have saved nothing at all.


I usually do not encourage people to optimize correctness out of their code.

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

Re: [Tutor] beginning to code

[Stephan Houben]

Op 2017-09-23, Rick Johnson schreef :
> These pissing contests over how values are passed in Python
> are totally irrelevant. What does it matter? Nothing will be
> gained or lost by arguing over which is true, or not. Unless
> the distinction is preventing you from doing something that
> you'd like to do, or unless you want to argue that one
> "value passing method" would bring X, Y or Z benefits over
> the other, what does it matter?

Amen.

For what it's worth, this discussion lead me to do a bit of historical
research into how these terminologies came to be (also to see if there
is some sort of "official" definition of what they actually mean).

The earliest to which I can trace the discussion is on the context of
the definition of the Algol programming language. Algol had both
"call by value" and "call by name".

Then the whole "call by XXX" terminology took off and people started
talking about "call by copy in/out" and whatever. The "call by
reference" terminology was introduced to describe what Fortran had been
doing all along.

The CLU people (primary Barbara Liskov) introduced "call by object
sharing", to describe what CLU did. This matches pretty well what Python
does, and what Java does, and what basically every programming language
invented in the last 25 years does.

Now, as I said, what Java and what CLU do is pretty similar, but in
the Java community this very same thing is called "call by value".
As far as I can follow, this is for the following reason:

 * The Algol report invented "call by value" and "call by name" and was
   very influential.

 * In particular, the Report on the Scheme language was heavily
   influenced by the Algol report. In the Scheme report, Scheme is
   described as being "call by value", again probably because of
   influence of the Algol report, and Scheme is definitely NOT
   "call by name". Note that in our terminology, Scheme should
   properly be called "call by object [sharing]".

 * Guy Steele, who was involved in the Scheme standard, then went 
   on to work on the Java language definition.

So Java got its terminology from the Algol->Scheme->Java route.
Python got it from CLU.

As an aside, in the academic literature, "call by value" is almost
always contrasted with "call by name" (nobody seems to have ever
published a paper discussing "call by reference").
Typically, this comparison is done in calculi which even lack
assignment so that the difference between call by value and call by
reference would be unobservable anyway.

Stephan
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Tutor] beginning to code

[Rick Johnson]

Mark Lawrence wrote:
> [...] 
> I have no interest it what the C++ does, looks like or
> anything else. All I'm bothered about is that two highly
> respected members of the Python community have stated quite
> clearly that Python is call by object.  Many other people
> have stated the same in this thread or previously, yet
> still people who know squat about Python continue to debate
> the subject.  Why waste effort going over old ground?  Is
> it completely impossible for people to step outside of
> their world of pass by value or pass by reference?

This is one of those rare times when i agree with Mark (and
excuse me for a sec whilst i pinch myself...).

These pissing contests over how values are passed in Python
are totally irrelevant. What does it matter? Nothing will be
gained or lost by arguing over which is true, or not. Unless
the distinction is preventing you from doing something that
you'd like to do, or unless you want to argue that one
"value passing method" would bring X, Y or Z benefits over
the other, what does it matter?

It's like arguing that red lights should be green and green
lights should be red. What are the pros and cons of such
change? IOW, the argument lacks _substance_.

If you're going to argue. At least do it correctly. And try
to make the battle at least _slightly_ entertaining. Folks,
there is reason why flag football never became as popular as
its full-contact sister. 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Tutor] beginning to code

[Mark Lawrence via Python-list]

On 23/09/2017 04:06, Bill wrote:

Mark Lawrence wrote:

On 22/09/2017 08:01, Bill wrote:

Steve D'Aprano wrote:

On Fri, 22 Sep 2017 02:57 pm, Bill wrote:


I find Python to be more more
like Java, with regard to "passing objects by reference".
Which is not a surprise, since both Python and Java use the same 
value passing

style: pass by object reference, or pass by sharing if you prefer.

Java people don't call it that. They call it pass by value, and 
categorically
deny that it is pass by reference. (They're right about the second 
point.)


I figure that, internally, an address, a pointer, is being passed by 
value to implement pass by reference.  Why do you say "they are 
right" above? Are you saying it's not pass by reference?




Please see 
http://jeffknupp.com/blog/2012/11/13/is-python-callbyvalue-or-callbyreference-neither/ 
and http://effbot.org/zone/call-by-object.htm





I would would agree with the description provided for the C++ example 
provided


string some_guy = "fred";
  is replaced by
char* some_guy="fred";

To see that this is correct, note the some_guy may subsequently be 
assigned to a character string much longer then "fred".  An additional 
note: A character string literal, like "cat", never occurs more than 
once in compiled C++ program unit.  This also shows that the provided 
description can't be completely correct. One last thing,


string some_guy = "fred"

is really the same thing as

string some_guy("fred");

and both equivalently call the string constructor.

The data type of "fred" is const char*, not (class) string.



I have no interest it what the C++ does, looks like or anything else. 
All I'm bothered about is that two highly respected members of the 
Python community have stated quite clearly that Python is call by 
object.  Many other people have stated the same in this thread or 
previously, yet still people who know squat about Python continue to 
debate the subject.  Why waste effort going over old ground?  Is it 
completely impossible for people to step outside of their world of pass 
by value or pass by reference?


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

---
This email has been checked for viruses by AVG.
http://www.avg.com


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

Re: [Tutor] beginning to code

[Bill]

Bill wrote:

Mark Lawrence wrote:

On 22/09/2017 08:01, Bill wrote:

Steve D'Aprano wrote:

On Fri, 22 Sep 2017 02:57 pm, Bill wrote:


I find Python to be more more
like Java, with regard to "passing objects by reference".
Which is not a surprise, since both Python and Java use the same 
value passing

style: pass by object reference, or pass by sharing if you prefer.

Java people don't call it that. They call it pass by value, and 
categorically
deny that it is pass by reference. (They're right about the second 
point.)


I figure that, internally, an address, a pointer, is being passed by 
value to implement pass by reference.  Why do you say "they are 
right" above? Are you saying it's not pass by reference?




Please see 
http://jeffknupp.com/blog/2012/11/13/is-python-callbyvalue-or-callbyreference-neither/ 
and http://effbot.org/zone/call-by-object.htm





I would would agree with the description provided for the C++ example 
provided


string some_guy = "fred";
 is replaced by
char* some_guy="fred";


On second thought, so that the description is correct (matches the 
semantics), replace it by


char some_guy[10]="fred";

But then you need to use std::strcpy to reassign some_guy
to "george".








To see that this is correct, note the some_guy may subsequently be 
assigned to a character string much longer then "fred".  An additional 
note: A character string literal, like "cat", never occurs more than 
once in compiled C++ program unit.  This also shows that the provided 
description can't be completely correct. One last thing,


string some_guy = "fred"

is really the same thing as

string some_guy("fred");

and both equivalently call the string constructor.

The data type of "fred" is const char*, not (class) string.


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

Re: [Tutor] beginning to code

[Bill]

Mark Lawrence wrote:

On 22/09/2017 08:01, Bill wrote:

Steve D'Aprano wrote:

On Fri, 22 Sep 2017 02:57 pm, Bill wrote:


I find Python to be more more
like Java, with regard to "passing objects by reference".
Which is not a surprise, since both Python and Java use the same 
value passing

style: pass by object reference, or pass by sharing if you prefer.

Java people don't call it that. They call it pass by value, and 
categorically
deny that it is pass by reference. (They're right about the second 
point.)


I figure that, internally, an address, a pointer, is being passed by 
value to implement pass by reference.  Why do you say "they are 
right" above? Are you saying it's not pass by reference?




Please see 
http://jeffknupp.com/blog/2012/11/13/is-python-callbyvalue-or-callbyreference-neither/ 
and http://effbot.org/zone/call-by-object.htm





I would would agree with the description provided for the C++ example 
provided


string some_guy = "fred";
 is replaced by
char* some_guy="fred";

To see that this is correct, note the some_guy may subsequently be 
assigned to a character string much longer then "fred".  An additional 
note: A character string literal, like "cat", never occurs more than 
once in compiled C++ program unit.  This also shows that the provided 
description can't be completely correct. One last thing,


string some_guy = "fred"

is really the same thing as

string some_guy("fred");

and both equivalently call the string constructor.

The data type of "fred" is const char*, not (class) string.
--
https://mail.python.org/mailman/listinfo/python-list

Re: [Tutor] beginning to code

[Marko Rauhamaa]

Chris Angelico :

> On Fri, Sep 22, 2017 at 10:26 PM, Marko Rauhamaa  wrote:
>> Chris Angelico :
>>> (Side point: Your slot_ref function is rather bizarre. It's a closure
>>> AND a class, just in case one of them isn't sufficient.
>>
>> I don't see anything bizarre in it at all.

> Sure you *can* do it. It's perfectly legal Python syntax. But what's
> the point? The class alone will do it.
>
> class slot_ref:
> def __init__(self, ns, key):
> self.ns = ns; self.key = key
> def get(self): return self.ns[self.key]
> def set(self, value): self.ns[self.key] = value
>
> That should be drop-in compatible with your original function/class
> hybrid, complete with following the naming convention for functions
> rather than classes.

You are right. That one would be the way to go here.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Tutor] beginning to code

[Chris Angelico]

On Fri, Sep 22, 2017 at 10:26 PM, Marko Rauhamaa  wrote:
> Chris Angelico :
>> (Side point: Your slot_ref function is rather bizarre. It's a closure
>> AND a class, just in case one of them isn't sufficient.
>
> I don't see anything bizarre in it at all. I use the pattern all the
> time. It's called an inner class:
>
>In Python, it is possible to nest a class within another class,
>method or function.
>
>https://en.wikipedia.org/wiki/Inner_class#Programming_languages>

Sure you *can* do it. It's perfectly legal Python syntax. But what's
the point? The class alone will do it.

class slot_ref:
def __init__(self, ns, key):
self.ns = ns; self.key = key
def get(self): return self.ns[self.key]
def set(self, value): self.ns[self.key] = value

That should be drop-in compatible with your original function/class
hybrid, complete with following the naming convention for functions
rather than classes.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Tutor] beginning to code

[Steve D'Aprano]

On Fri, 22 Sep 2017 10:27 pm, Marko Rauhamaa wrote:

> r...@zedat.fu-berlin.de (Stefan Ram):
> 
>> Marko Rauhamaa  writes:
>>>swap(slot_ref(locals(), "x"), slot_ref(locals(), "y"))
>>
>>   You need to be able to write the call as
>>
>> swap( x, y )
> 
> Why?

Because that's the whole point of the exercise.

The exercise isn't to demonstrate how to swap two variables. In Python, that's
easy:

a, b = b, a

The exercise is to demonstrate pass by reference semantics. That requires
demonstrating the same semantics as the Pascal swap procedure:

procedure swap(var a, var b):
  begin
tmp := a;
a := b;
b := tmp;
  end;

(ignoring the type declarations for brevity).

Call by reference semantics enable you to call swap(x, y) to swap x and y in the
caller's scope. You don't call swap('x', 'y', scope_of_x, scope_of_y) or any
other variant. That isn't call by reference semantics.

The whole point of call by reference semantics is that the *compiler*, not the
programmer, tracks the variables and their scopes. The programmer just
says "swap x and y", and the compiler works out how to do it.


-- 
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: [Tutor] beginning to code

[bartc]

On 22/09/2017 13:34, Steve D'Aprano wrote:

On Fri, 22 Sep 2017 09:24 pm, Marko Rauhamaa wrote:



Yes, following my recipe:

def swap(ref_a, ref_b):
a, b = ref_a.get(), ref_b.get()
ref_a.set(b)
ref_b.set(a)

x = 10
y = "Z"
swap(slot_ref(locals(), "x"), slot_ref(locals(), "y"))
print(x, y) # "Z" and 10



No, you failed to follow Bart's instructions and answered a different question.



You have to pass x and y, not strings 'x' and 'y'. The swap procedure needs to
accept any variable, given as ordinary bare names swap(x, y), not written as
strings, or by hard-coding x and y as the variables to swap, or by using a
string and passing it to exec, or any other loophole.


And being able to pass any lvalue expression, not just simple variable 
names. Such as a[i] or x.y, provided the term is mutable.


(To make it work would require a new reference type. And extra versions 
of the byte-codes or whatever is used to evaluate terms such as:


a, a[i], x.y

that evaluate a reference rather than the value. So LOADFASTREF as well 
as LOADFAST)


--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: [Tutor] beginning to code

[Marko Rauhamaa]

r...@zedat.fu-berlin.de (Stefan Ram):

> Marko Rauhamaa  writes:
>>r...@zedat.fu-berlin.de (Stefan Ram):
>>>Marko Rauhamaa  writes:
swap(slot_ref(locals(), "x"), slot_ref(locals(), "y"))
>>>You need to be able to write the call as
>>>swap( x, y )
>>Why?
>
>   You responded to Bart:
>
> | swap(x,y)
> | print (x,y) # "Z" and "10"
> |
> |If not, then it doesn't have reference passing as
> |it is normally understood.
>
>   , and Bart required this form. Moreover, if you allow other
>   forms, such as
>
> swap( ,  )
>
>   , then even C, would have "call by reference",
>   but it has not.

There's two things: syntax and semantics.

Obviously, Bart's syntax couldn't work syntactically unless Python added
the syntactic facilities. But the bigger question is a semantic one: is
it possible regardless of syntactic considerations.

As Chris pointed out, Python has explicitly ruled it out with the
immutability caveat to locals().


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Tutor] beginning to code

[Steve D'Aprano]

On Fri, 22 Sep 2017 09:24 pm, Marko Rauhamaa wrote:

> bartc :
> 
>> On 22/09/2017 10:23, Marko Rauhamaa wrote:
>>> However, Python doesn't need any language changes to implement memory
>>> slots. A memory slot could be defined as any object that implements
>>> "get()" and "set(value)" methods:
>>
>> I didn't understand your examples.
>>
>> Can Python be used to write, say, a swap() function that works with any
>> argument types (not just classes or lists)? Example:
>>
>> def swap(,):# made up syntax
>> a, b = b, a
>>
>> x=10
>> y="Z"
>> swap(x,y)
>> print (x,y) # "Z" and "10"
> 
> Yes, following my recipe:
> 
>def swap(ref_a, ref_b):
>a, b = ref_a.get(), ref_b.get()
>ref_a.set(b)
>ref_b.set(a)
> 
>x = 10
>y = "Z"
>swap(slot_ref(locals(), "x"), slot_ref(locals(), "y"))
>print(x, y) # "Z" and 10


No, you failed to follow Bart's instructions and answered a different question.

"Can you pulverise this granite boulder with your bare hands?"

"Sure! I just need to use this sledge hammer, and pulverise this small sandstone
rock instead."


You have to pass x and y, not strings 'x' and 'y'. The swap procedure needs to
accept any variable, given as ordinary bare names swap(x, y), not written as
strings, or by hard-coding x and y as the variables to swap, or by using a
string and passing it to exec, or any other loophole.

Also, you're assuming that locals() is writable, which in the most general case
it is not. Try using locals from inside a function, rather than in the global
scope.

You made a good attempt to emulate pass by reference via an extra layer of
indirection. Pity that it doesn't solve the problem and doesn't work.

Here's an easy way to emulate pass by reference which works in any scope: use a
list.


def swap(a, b):
a[0], b[0] = b[0], a[0]


a = [1]
b = [2]
swap(a, b)
assert a[0] == 2 and b[0] == 1


It's not proper pass by reference, and so will still fail Bart's test, because
you need to manually add an extra layer of redirection (using a list). Its like
using a pointer in C to emulate references, compared to having actual language
support for them like in Pascal or C++.

But if I wanted to write a Pascal interpreter in Python, I could use something
like this to implement Pascal var parameters.



-- 
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: [Tutor] beginning to code

[Marko Rauhamaa]

r...@zedat.fu-berlin.de (Stefan Ram):

> Marko Rauhamaa  writes:
>>swap(slot_ref(locals(), "x"), slot_ref(locals(), "y"))
>
>   You need to be able to write the call as
>
> swap( x, y )

Why?


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Tutor] beginning to code

[Marko Rauhamaa]

Chris Angelico :

> Sure, let me just put that into a function. CPython 3.7, although I'm
> pretty sure most CPython versions will do the same, as will several of
> the other Pythons.
> [demonstration that it didn't work]

Ok. The reason is this:

   Note: The contents of this dictionary should not be modified; changes
   may not affect the values of local and free variables used by the
   interpreter.

   https://docs.python.org/3/library/functions.html#locals>

So the language specification explicitly ruled it out, unfortunately.

> (Side point: Your slot_ref function is rather bizarre. It's a closure
> AND a class, just in case one of them isn't sufficient.

I don't see anything bizarre in it at all. I use the pattern all the
time. It's called an inner class:

   In Python, it is possible to nest a class within another class,
   method or function.

   https://en.wikipedia.org/wiki/Inner_class#Programming_languages>


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Tutor] beginning to code

[Mark Lawrence via Python-list]

On 22/09/2017 10:53, Bill wrote:
I just wanted to mention that my comment was made in the context that 
Python is implemented by an interpreter written in C.   I realize that 
this may not always be the case.  However, I haven't heard anyone 
mention a Python interpreter written in Python yet.


The reference implementation is written in C but there's also Jython 
(Java) and IronPython (.Net).


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

---
This email has been checked for viruses by AVG.
http://www.avg.com


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