1

So I have been using python for quite a while without knowing some of the nuances. Recently I discovered that when assigning an old variable to a new variable, what being assigned is just a reference to the old variable instead of the actual value of it. So I did a little test:

def change_number(b):
    a=b
    a+=1
    return a, b


b=1

print(change_number(b))

def change_list(b):
    a=b
    a.append("x")

    return a,b

b=["a","b"]

print(change_list(b))

The results are:

(2, 1)
(['a', 'b', 'x'], ['a', 'b', 'x'])

It seems that when dealing with numbers, python are treating the variables separately. Whereas when dealing with lists, a single instance beneath the two references is updated regardless of which one the operation is called upon.

I am thinking that this difference might be related to the types of objects python is dealing with, but it seems that it may also have something to do with the operation being done. I have read several related answers with respect to specific problems, but I would really like to know the general rule of python dealing with new variable assignments related to existing ones under difference circumstances. Cheers

7
  • 3
    You've got a bunch of misunderstandings here. It sounds like you could use a quick guide to how Python variables and objects work: nedbatchelder.com/text/names.html Commented Dec 13, 2020 at 0:30
  • "It seems that when dealing with numbers, python are treating the variables separately. '" No. Assignment always has reference semantics. The type of the object the variable is referring to is completely irrelevant. In the first case, you mutated the dict. In the second case, you create a new int and re-assign it. int objects happen to be immutable, so you cant change them, but the semantics of assignment are exactly the same. I second the call to read: nedbatchelder.com/text/names.html Commented Dec 13, 2020 at 0:41
  • so, for example if in change_list you did a = a + [42] you would see the same effect. Commented Dec 13, 2020 at 0:41
  • @Moosefeather no the data type is irrelevant. It always works the same way Commented Dec 13, 2020 at 0:42
  • 1
    Yes, + on lists creates a new list. (+= on lists does not, though. The inequivalence of x += y and x = x + y for mutable types is a frequent source of confusion for new Python programmers.) Commented Dec 13, 2020 at 4:14

1 Answer 1

2

= always creates a new reference, and never creates a new object.

What you're seeing is the difference between += and .append(). Integers in Python are immutable, so when you try to change it you have no choice but to reference a different object - the 1 will always be 1. On the other hand lists are mutable, so .append() can change the single list object and add something new to the end of it.

Sign up to request clarification or add additional context in comments.

3 Comments

To be pedantic, operations on lists may or may not mutate the underlying list, that is up to the designer of the API. Indeed, all that an object being immutable means is that the API doesn't expose any way to mutate the object. You can hackily mutate an int object if you really want to (and if you are a fan of segfaults)
@juanpa.arrivillaga for lists, the designer of the API would be GVR himself. He's unlikely to change it unless he gets a sudden bout of dementia. I'd be interested in knowing the hacks that could make an integer mutable. Reminds me of the early versions of Fortran, where passing a constant into a function would allow you to change the constant because parameters were always passed by pointer.
See: reddit.com/r/Python/comments/2441cv/… basically, if you understand the layout of the PyLongObject struct in C, you can use ctypes to manipulate it, given the address. Of course, this all relies on CPython implementation details.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.