[issue33835] Too strong side effect?

[X. Yan]

X. Yan  added the comment:

I see.

Thanks for the detailed explanations.

Best,

Xiaogang

On 6/11/2018 2:00 PM, Steven D'Aprano wrote:
> Steven D'Aprano  added the comment:
>
> Both names "v1" and "v2" refer to the same object. Python does not make 
> copies of objects on assignment, so if you write:
>
> a = []
> b = a
>
> then a and b both refer to the same list object, and the names "a" and "b" 
> are effectively aliases. This is standard object-sharing behaviour used by 
> many languages, including Lisp, Ruby, Javascript and Java.
>
> If you are familiar with languages like Pascal and C++ you are probably 
> thinking that variables are boxes at fixed memory locations, and assignment 
> copies values into that box. That is not a good model for Python (and others).
>
> This is not a bug. If you are unfamiliar with this object model, it can seem 
> a bit strange at first, but for people who are used to Python, the C and 
> Pascal model seems strange too.
>
> Some people call this distinction Values Types (like Pascal and C) versus 
> Reference Types (like Python, Ruby, Javascript)
>
> https://softwareengineering.stackexchange.com/questions/314808/why-variables-in-python-are-different-from-other-programming-languages
>
> --
> nosy: +steven.daprano
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33835] Too strong side effect?

[R. David Murray]

Change by R. David Murray :


--
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33835] Too strong side effect?

[Steven D'Aprano]

Steven D'Aprano  added the comment:

Both names "v1" and "v2" refer to the same object. Python does not make copies 
of objects on assignment, so if you write:

a = []
b = a

then a and b both refer to the same list object, and the names "a" and "b" are 
effectively aliases. This is standard object-sharing behaviour used by many 
languages, including Lisp, Ruby, Javascript and Java.

If you are familiar with languages like Pascal and C++ you are probably 
thinking that variables are boxes at fixed memory locations, and assignment 
copies values into that box. That is not a good model for Python (and others).

This is not a bug. If you are unfamiliar with this object model, it can seem a 
bit strange at first, but for people who are used to Python, the C and Pascal 
model seems strange too.

Some people call this distinction Values Types (like Pascal and C) versus 
Reference Types (like Python, Ruby, Javascript)

https://softwareengineering.stackexchange.com/questions/314808/why-variables-in-python-are-different-from-other-programming-languages

--
nosy: +steven.daprano

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33835] Too strong side effect?

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

See 
https://docs.python.org/3/faq/programming.html#why-did-changing-list-y-also-change-list-x
 .

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33835] Too strong side effect?

[X. Yan]

X. Yan  added the comment:

Hi Serhiy,

Thanks for your reply. However, the issue I reported was not about sharing the 
default value. I understand that the parameter L would keep its value [1] from 
function f's first run, and used it in the second run to get [1, 2].

My point is that the variable v1 only got involved in f's first run. It should 
keep the result [1] since then. The second calling v2=f(2) is irrelevant to v1, 
therefore, v1's content shouldn't be changed. v1 should be independent from f's 
later activities. Please let me know if this makes sense.

--
status: closed -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33835] Too strong side effect?

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

See 
https://docs.python.org/3/faq/programming.html#why-are-default-values-shared-between-objects
 .

--
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33835] Too strong side effect?

[X. Yan]

New submission from X. Yan :

I am familiar with quite a few languages such as C++, C, PASCAL, Matlab, etc., 
but starting to practice Python. When I tested the code:

def f(a, L=[]):
L.append(a)
return L

followed by calls as follows,

v1 = f(1)
v2 = f(2)

, to my surprise, I saw the v1's content was changed from initial [1] to [1, 
2], when the second call, v2=f(2), was executed. This means when you produce 
the new value for v2, you have to be very very careful for all the results 
produced by this function previously, such as what in the v1. They can be 
changed in the background! I wonder if this side-effect was designed on 
purpose, or is actually a BUG, because it is too dangerous.

--
messages: 319308
nosy: xgyan
priority: normal
severity: normal
status: open
title: Too strong side effect?
type: behavior
versions: Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com