-
Notifications
You must be signed in to change notification settings - Fork 72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No copies on assignment #6
Comments
Ryan is right. This needs to be fixed—not sure how this got in there. We’d better check for other such errors |
Here's an excerpt from a newer version of the lab (being merged in soon):
The more I look at this lab, the more I want to rewrite some of it to do a better treatment of namespaces and mutability anyway, but this should be a sufficient patch for now. |
@shanemcq18, there is an important subtlety that needs to be addressed. What happens when your immutable object contains a reference to a mutable object? The description needs to emphasize that what makes a container immutable is the inability to change the references after object creation. However, if you are pointing to a mutable object inside an immutable container, then you can still change the mutable object since the reference stays the same. a = [1]
b = (1, a)
# b is (1, [1])
a.append(2)
# b is now (1, [1, 2])
c = b + (4,) # c is a new tuple: (1, [1, 2], 4)
a.append(3)
# b is now (1, [1, 2, 3])
# c is now (1, [1, 2, 3], 4) It would be very easy for a beginner to assume that |
This paragraph is incorrect.
https://github.com/Foundations-of-Applied-Mathematics/Labs/blob/master/PythonEssentials/StandardLibrary/StandardLibrary.tex#L151
Assigning a new name to an immutable object does not create a copy. Both names simply point to the same object in memory. IIRC, assignments in Python never create copies.
The text was updated successfully, but these errors were encountered: