[issue33835] Too strong side effect?
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 <https://bugs.python.org/issue33835> ___ ___ 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 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 <https://bugs.python.org/issue33835> ___ ___ 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 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 > <https://bugs.python.org/issue33835> > ___ > -- ___ Python tracker <https://bugs.python.org/issue33835> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
