Too strong side effect?

[xgyan]

BPO	33835
Nosy	@stevendaprano, @serhiy-storchaka

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2018-06-11.19:33:56.001>
created_at = <Date 2018-06-11.15:42:19.899>
labels = ['type-bug', 'invalid']
title = 'Too strong side effect?'
updated_at = <Date 2018-06-11.19:45:48.318>
user = 'https://bugs.python.org/xgyan'

bugs.python.org fields:

activity = <Date 2018-06-11.19:45:48.318>
actor = 'xgyan'
assignee = 'none'
closed = True
closed_date = <Date 2018-06-11.19:33:56.001>
closer = 'r.david.murray'
components = []
creation = <Date 2018-06-11.15:42:19.899>
creator = 'xgyan'
dependencies = []
files = []
hgrepos = []
issue_num = 33835
keywords = []
message_count = 6.0
messages = ['319308', '319309', '319322', '319324', '319325', '319333']
nosy_count = 3.0
nosy_names = ['steven.daprano', 'serhiy.storchaka', 'xgyan']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue33835'
versions = ['Python 3.6']

[xgyan]

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.

[serhiy-storchaka]

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

[xgyan]

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.

[serhiy-storchaka]

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

[stevendaprano]

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

[xgyan]

I see.

Thanks for the detailed explanations.

Best,

Xiaogang

On 6/11/2018 2:00 PM, Steven D'Aprano wrote:

Steven D'Aprano <steve+python@pearwood.info> 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 <report@bugs.python.org>
<https://bugs.python.org/issue33835\>

---