classification
Title: A matrix (list of lists) behaves differently, depending how it is created
Type: behavior Stage: resolved
Components: Tests Versions: Python 3.6
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: ezio.melotti, jjhwoldringh, xtreak
Priority: normal Keywords:

Created on 2020-01-17 12:55 by jjhwoldringh, last changed 2020-01-17 15:13 by jjhwoldringh. This issue is now closed.

Files
File name Uploaded Description Edit
matrix_experiment.py jjhwoldringh, 2020-01-17 12:55
code.py jjhwoldringh, 2020-01-17 15:13
Messages (4)
msg360182 - (view) Author: Jaap Woldringh (jjhwoldringh) Date: 2020-01-17 12:55
Python used:
Python 3.6.9 (default, Nov  7 2019, 10:44:02) 
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
In Ubuntu 18.04.3

But in any other version of Python3, and Python2,  that I tried, the behaviour of a (square) matrix depends on how it is created; as I can demonstrate in a test program matrix_experiment.py that is attached to this report.

1. it behaves as expected when created by entering all it’s elements like so:
A = [[ 1,2,3],[1,2,3],[1,2,3]]

2. If it is created by appending predefined rows, it behaves as if all rows are the same as the last row:
row = [1,2,3]
B=[]
for i in range(3):
    B.appends(row)

The result matrix is the same as A:   [[1, 2, 3], [1, 2, 3], [1, 2, 3]]

Both results are equal:

print(A==B) gives True.

But when using B the result is disastrous as the attached matrix_experiment.py
program shows.

I consider this a very serious bug, and first filed it at Ubuntu’s Launchpad, but I don't find it there.
So now I file this again, at Python.org itself, using my new account.
msg360184 - (view) Author: Karthikeyan Singaravelan (xtreak) * (Python committer) Date: 2020-01-17 13:03
You're referencing to the same list 3 times in B. So modifying it once means all the elements referring to same object reflect the change. Make a copy of the list during append to ensure modification of one doesn't affect other. This is not a python bug.
msg360185 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2020-01-17 13:08
See also https://docs.python.org/3/faq/programming.html#why-did-changing-list-y-also-change-list-x

You can use the builtin function id() to see the id of the lists, and verify whether they refer to the same object or not.
msg360195 - (view) Author: Jaap Woldringh (jjhwoldringh) Date: 2020-01-17 15:13
Op 17-01-2020 om 14:03 schreef Karthikeyan Singaravelan:
> Karthikeyan Singaravelan <tir.karthi@gmail.com> added the comment:
>
> You're referencing to the same list 3 times in B. So modifying it once means all the elements referring to same object reflect the change. Make a copy of the list during append to ensure modification of one doesn't affect other. This is not a python bug.
>
> ----------
> nosy: +xtreak
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue39368>
> _______________________________________

Ah, I see! Thank you for pointing this out to me! I have been pondering 
this for days on end on what was happening here.

This behaviour of Python is very frustrating, and even if "it is not a 
bug" (I knew it!) it's very nasty, and shouldn't be. Your suggestion of 
making a copy of the list during the append saves my day! And Python itself!

I was creating a very simple program for encrypting a sentence using a 
square matrix, and expected a one hour job at most. It became days, and 
I finally created a very simple method, without a rxk matrix itself, but 
using the idea!

So, if possible, please, improve Python so that this feature doesn't 
cause these unnecessary problems. Meanwhile I retract my bug report!

To my opinion this feature of Python, having aparently same objects 
refer to the same addresses in memory, was useful in times long ago when 
memory was expensive. But now this feature is not feature at all. To my 
opinion :)

Gtsori menf egr

Jaap Woldringh
History
Date User Action Args
2020-01-17 15:13:06jjhwoldringhsetfiles: + code.py

messages: + msg360195
2020-01-17 13:08:29ezio.melottisetstatus: open -> closed

nosy: + ezio.melotti
messages: + msg360185

resolution: not a bug
stage: resolved
2020-01-17 13:03:07xtreaksetnosy: + xtreak
messages: + msg360184
2020-01-17 12:55:23jjhwoldringhcreate