Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Mutability of function arguments?

Reply
Thread Tools

Mutability of function arguments?

 
 
bonono@gmail.com
Guest
Posts: n/a
 
      12-08-2005

Mike Meyer wrote:
> http://www.velocityreviews.com/forums/(E-Mail Removed) writes:
> > Mike Meyer wrote:
> >> "ex_ottoyuhr" <(E-Mail Removed)> writes:
> >> > I'm trying to create a function that can take arguments, say, foo and
> >> > bar, and modify the original copies of foo and bar as well as its local
> >> > versions -- the equivalent of C++ funct(&foo, &bar).
> >>
> >> C++'s '&' causes an argument to be passed by reference. Python does
> >> that with all arguments. Any changes you make to the argument in the
> >> function will be seen in the caller unless you explicitly make a copy
> >> to pass.
> >>

> > except when foo and bar are bound to immutable objects.

>
> Wrong.
>
> > In C:
> >
> > int foo=1;
> > int bar=2;
> >
> > void update(int *a, int *b) { *a=3; *b=4}
> >
> > update(&foo, &bar);

>
> Note that this update is using an assignment statement, and thus
> changing the arguments.


void update(int a, int b) { a=3; b=4}

Is this also an assignment statement ?

>
> > In Python:
> >
> > foo=1
> > bar=2
> >
> > def update(a,b): a=3; b=4
> >
> > update(foo,bar)

>
> This update isn't changing the objects, it's rebinding the names in
> the local name space. Since you didn't change the objects, there's no
> change to see in the calling environment.
>
> > Many people from C/C++ background would be tricked for this situation.

>
> That's because they don't understand binding. Any language that has
> bindings instead of has assignments will "trick" them this way.
>

Sure, any language that behave like this would trick them, I am not
saying python is the only one or that there is anything wrong with this
behaviour. I was just saying that it is a situation that they get
tricked, because of their "perception" about "=", especially when they
are told that any change to the arguments are seen by the caller.

 
Reply With Quote
 
 
 
 
Mike Meyer
Guest
Posts: n/a
 
      12-08-2005
(E-Mail Removed) writes:
> Mike Meyer wrote:
>> (E-Mail Removed) writes:
>> > Mike Meyer wrote:
>> >> "ex_ottoyuhr" <(E-Mail Removed)> writes:
>> >> > I'm trying to create a function that can take arguments, say, foo and
>> >> > bar, and modify the original copies of foo and bar as well as its local
>> >> > versions -- the equivalent of C++ funct(&foo, &bar).
>> >> C++'s '&' causes an argument to be passed by reference. Python does
>> >> that with all arguments. Any changes you make to the argument in the
>> >> function will be seen in the caller unless you explicitly make a copy
>> >> to pass.
>> > except when foo and bar are bound to immutable objects.

>> Wrong.
>> > In C:
>> >
>> > int foo=1;
>> > int bar=2;
>> >
>> > void update(int *a, int *b) { *a=3; *b=4}
>> >
>> > update(&foo, &bar);

>>
>> Note that this update is using an assignment statement, and thus
>> changing the arguments.

> void update(int a, int b) { a=3; b=4}
> Is this also an assignment statement ?


Yes. But C calls by value, and passes copies of the original a and b
in. So in this case, you change the copies.

>> > In Python:
>> >
>> > foo=1
>> > bar=2
>> >
>> > def update(a,b): a=3; b=4
>> >
>> > update(foo,bar)

>> This update isn't changing the objects, it's rebinding the names in
>> the local name space. Since you didn't change the objects, there's no
>> change to see in the calling environment.
>> > Many people from C/C++ background would be tricked for this situation.

>> That's because they don't understand binding. Any language that has
>> bindings instead of has assignments will "trick" them this way.

> Sure, any language that behave like this would trick them, I am not
> saying python is the only one or that there is anything wrong with this
> behaviour. I was just saying that it is a situation that they get
> tricked, because of their "perception" about "=", especially when they
> are told that any change to the arguments are seen by the caller.


Except "trick" is a poor word choice. Nobody is playing a trick on
them - they just don't understand what is going on.

<mike
--
Mike Meyer <(E-Mail Removed)> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
 
Reply With Quote
 
 
 
 
bonono@gmail.com
Guest
Posts: n/a
 
      12-08-2005

Mike Meyer wrote:
> Except "trick" is a poor word choice. Nobody is playing a trick on
> them - they just don't understand what is going on.
>

oops, never thought about the negative meaning of it, it is just meant
as "not behave as expected", what would be the word you use then ?

 
Reply With Quote
 
Mike Meyer
Guest
Posts: n/a
 
      12-08-2005
(E-Mail Removed) writes:

>> Except "trick" is a poor word choice. Nobody is playing a trick on
>> them - they just don't understand what is going on.

> oops, never thought about the negative meaning of it, it is just meant
> as "not behave as expected", what would be the word you use then ?


Surprise?

<mike
--
Mike Meyer <(E-Mail Removed)> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
 
Reply With Quote
 
bruno at modulix
Guest
Posts: n/a
 
      12-08-2005
ex_ottoyuhr wrote:
> I'm trying to create a function that can take arguments, say, foo and
> bar, and modify the original copies of foo and bar as well as its local
> versions -- the equivalent of C++ funct(&foo, &bar).


This is already what you have. In Python, all you have are references to
objects, there is no "local version".

> I've looked around on this newsgroup and elsewhere, and I gather that
> this is a very common concern in Python, but one which is ordinarily
> answered with "No, you can't. Neat, huh?"


Pardon ???

>>> def appendToList(aList, aValue):

.... aList.append(aValue)
....
>>> mylist = range(10)
>>> mylist

[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>> appendToList(mylist, 42)
>>> mylist

[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 42]
>>>


Now the usual considerations apply :
- rebinding an arg has of course only local effect
- immutable objects are still immutables

Also note that since
1/ Python as a good support for exception handling
2/ a function can return multiple values [1],
there is less need for such constructs than in C or C++.

[1] the truth is that the function can return a unique tuple, that can
be unpacked as any other.

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '(E-Mail Removed)'.split('@')])"
 
Reply With Quote
 
Kent Johnson
Guest
Posts: n/a
 
      12-08-2005
Mike Meyer wrote:
> "ex_ottoyuhr" <(E-Mail Removed)> writes:
>
>>I'm trying to create a function that can take arguments, say, foo and
>>bar, and modify the original copies of foo and bar as well as its local
>>versions -- the equivalent of C++ funct(&foo, &bar).

>
>
> C++'s '&' causes an argument to be passed by reference. Python does
> that with all arguments. Any changes you make to the argument in the
> function will be seen in the caller unless you explicitly make a copy
> to pass.


I would say, from the point of view of a C++ programmer, Python passes
references by value. In other words if you think of variables as
pointers (references) to values, and function call as passing the
reference by value, the behaviour of Python makes sense.

Kent
 
Reply With Quote
 
Mike Meyer
Guest
Posts: n/a
 
      12-08-2005
Kent Johnson <(E-Mail Removed)> writes:
> Mike Meyer wrote:
>> "ex_ottoyuhr" <(E-Mail Removed)> writes:
>>
>>>I'm trying to create a function that can take arguments, say, foo and
>>>bar, and modify the original copies of foo and bar as well as its local
>>>versions -- the equivalent of C++ funct(&foo, &bar).

>> C++'s '&' causes an argument to be passed by reference. Python does
>> that with all arguments. Any changes you make to the argument in the
>> function will be seen in the caller unless you explicitly make a copy
>> to pass.

> I would say, from the point of view of a C++ programmer, Python passes
> references by value. In other words if you think of variables as
> pointers (references) to values, and function call as passing the
> reference by value, the behaviour of Python makes sense.


While the description is right, the terminology is wrong, and places
the emphasis in the wrong place.

Your description of "passes references by value" is a description of
call by reference. C passes all arguments by value, to pass a
reference, the C programmer creates the reference to the value "by
hand", then dereferences it by hand at the other end. So C's
"call-by-reference" passes the reference by value. There's no
difference between C's call-by-reference and Python's
call-by-reference, and using different words to try and imply there is
will just cause problems further on.

The real difference is in the way names behave in the two
languages. As you put it, "variables are references to values", except
Python names don't have most of the things associated with variables
in other programming languages, so it's better to call them names. We
use "bound" to show that we're not copying a value over a fixed memory
location, hence "names are bound to values." This is the crucial
point, and the one that need to be emphasized.

<mike
--
Mike Meyer <(E-Mail Removed)> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
 
Reply With Quote
 
Fredrik Lundh
Guest
Posts: n/a
 
      12-08-2005
Mike Meyer wrote:

> Your description of "passes references by value" is a description of
> call by reference. C passes all arguments by value, to pass a
> reference, the C programmer creates the reference to the value "by
> hand", then dereferences it by hand at the other end. So C's
> "call-by-reference" passes the reference by value. There's no
> difference between C's call-by-reference and Python's
> call-by-reference, and using different words to try and imply there is
> will just cause problems further on.


can you guys please stop using "call by value" and "call by reference"
when you discuss Python. both terms have established meanings, and
Python's argument passing model doesn't match any of them.

this was known some 30 years ago; here's a quote from a CLU reference
manaual from 1979:

"We call the argument passing technique _call by sharing_,
because the argument objects are shared between the
caller and the called routine. This technique does not
correspond to most traditional argument passing techniques
(it is similar to argument passing in LISP). In particular IT
IS NOT call by value because mutations of arguments per-
formed by the called routine will be visible to the caller.
And IT IS NOT call by reference because access is not given
to the variables of the caller, but merely to certain objects."

(CLU was one of the first languages to use objects in the Python sense,
as well as the same argument passing model as today's Python)

established terms for Python's argument passing model are

call by object

or

call by sharing

for more on this, see the comp.lang.python archives.

</F>



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
how to test for atomicity/mutability/hashability? kj Python 4 10-07-2010 09:22 PM
Mutability, copying lists but not sharing? cnb Python 1 08-26-2008 12:56 AM
named tuple mutability castironpi@gmail.com Python 10 05-15-2008 10:43 AM
list mutability gigs Python 1 02-18-2008 07:40 PM
Mutability problem when subclassing tuple Edward C. Jones Python 2 02-19-2004 10:17 PM



Advertisments