Skip to content
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

Open
groutr opened this issue May 30, 2018 · 4 comments
Open

No copies on assignment #6

groutr opened this issue May 30, 2018 · 4 comments
Labels
bug Demo code isn't working

Comments

@groutr
Copy link

groutr commented May 30, 2018

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.

a = (1, 2, 3)  # immutable tuple
b = a    # b now references the same object as a
id(a) == id(a)    # True
@tylerjarvis
Copy link
Contributor

Ryan is right. This needs to be fixed—not sure how this got in there. We’d better check for other such errors

@shanemcq18 shanemcq18 added the bug Demo code isn't working label Jun 1, 2018
@shanemcq18
Copy link
Member

Here's an excerpt from a newer version of the lab (being merged in soon):

Every Python object type falls into one of two categories: a mutable object may be altered at any time, while an immutable object cannot be altered once created. Attempting to change an immutable object creates a new object in memory. If two names refer to the same mutable object, any changes to the object are reflected in both names since they still both refer to that same object. On the other hand, if two names refer to the same immutable object and one of the values is "changed," one name will refer to the original object, and the other will refer to a new object in memory.

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.

@groutr
Copy link
Author

groutr commented Jul 9, 2018

@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 b does not change after updating a, because b is immutable. Even though b is an immutable object, it can't be used as a key in a dictionary or member of a set.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Demo code isn't working
Projects
None yet
Development

No branches or pull requests

3 participants