this post was submitted on 02 Aug 2025
12 points (92.9% liked)

Python

7357 readers
57 users here now

Welcome to the Python community on the programming.dev Lemmy instance!

πŸ“… Events

PastNovember 2023

October 2023

July 2023

August 2023

September 2023

🐍 Python project:
πŸ’“ Python Community:
✨ Python Ecosystem:
🌌 Fediverse
Communities
Projects
Feeds

founded 2 years ago
MODERATORS
erlingur@programming.dev
jnovinger@programming.dev
norambna@programming.dev
12
A minor headache for a beginner coder (lemmy.dbzer0.com)
submitted 6 days ago by moosetwin@lemmy.dbzer0.com to c/python@programming.dev
14 comments fedilink hide all child comments
 

if var1 equals 1, and you run var2 = var1, that sets var2 to 1.

if list1 equals [1, 2, 3], and you run list2 = list1, that sets list2 to list1

so if you then run var1 = 2, var2 will still be 1

but if you run list1 = [3, 2, 1], list2 will give [3, 2, 1]

you are viewing a single comment's thread
view the rest of the comments
[–] gedhrel@lemmy.world 18 points 6 days ago (1 children)

It won't (using your example explicitly) but in general what you've discovered is that:

  1. Variables hold values
  2. Some of those values are references to shared mutable objects.

Lists fall into the second category. There are ways to copy lists if you want distinct behaviour.

list2 = list1[:]

will perform a "shallow copy". If you have a list of lists, however, the nested lists are still shared references. There is copy.deepcopy available to make a complete clone of something (including all its nested members).

[–] nickwitha_k@lemmy.sdf.org 6 points 6 days ago (1 children)

This. Collections (lists, dicts, tuples) behave a little differently than primitives.

[–] marcos@lemmy.world 3 points 6 days ago (1 children)

Every variable in Python is actually a reference (maybe optimized out, but still logically a reference). There's no difference.

Numbers, booleans, and None won't give you that kind of problem only because you can't change them.

[–] nickwitha_k@lemmy.sdf.org 1 points 6 days ago (1 children)

True. Since it's all interpreted, it doesn't act like primitives in things like C and everything is an object, that is a ref of some sort. However, there is a difference between how Python "primitives" and Python collections work within the language syntax.

[–] marcos@lemmy.world 1 points 6 days ago (1 children)

Now I'm curious what differences you are talking about, because I'm no Python expert, but I can't think of any. If you mean identity representation, no, it's not different:

>>> a = 65535
>>> b = 65535
>>> a is b
False
[–] nickwitha_k@lemmy.sdf.org 0 points 5 days ago* (last edited 5 days ago) (2 children)

I was meaning how they behave in when copying and similar behavior. One basically just needs to remember that assignment of a Python primitives var to another will copy the value, whereas doing the same thing with a collection will generally make a reference instead.

As for this:

>>> b = 65535
>>> a is b
False

I'd expect that behavior in must programming languages. It effectively translates to:

Allocate a variable "a" and assign it the value 65535

Allocate a variable "b" and assign it the value 65536

Is variable "a" literally the variable "b"? No

One could test with == to see if the values are equivalent but, unless "b" is assigned as "a", a is b should evaluate as false because they are two different variables.

[–] logging_strict@programming.dev 2 points 2 days ago

Other, maybe clearer, way to inspect references

id(a) == id(b)

Then reserve the use of is for bool or None.

Python has a concept of, Just don't do that. Which would be a great title for this topic thread.

[–] marcos@lemmy.world 1 points 5 days ago (1 children)

It doesn't seem to copy the value, just make another reference:

>>> a = 65535
>>> b = a
>>> b is a
True

One thing I know that Python does is optimize the value away for the few smallest values of the primitives. But that's on optimizations.

[–] nickwitha_k@lemmy.sdf.org 2 points 4 days ago (1 children)

Oh right! You are indeed correct. It is effectively just seeing a pointer there. What Python considers that to be is a shallow copy. But this only applies to "primitive" types. If you change the value of either, it will cease to act as a pointer to the same object but instead allocate a new one. It's a bit weird if one isn't used to all of that abstraction between oneself and the memory.

[–] marcos@lemmy.world 2 points 4 days ago

As I said, it's because you can't change the value of a primitive value. (That is, unless you abuse the C interface.)

Because Python doesn't protect classes, you just can't do the same with the types you create. But that's what is special, not the way if handles variables.

And this is different from languages like Java/C#, PHP/Perl, etc. Most imperative languages have primitive atomic values that go directly into your variables. But Python has only references (except for some complicated optimizations). Anyway, it is weird, and it's one of the reasons people should learn C or Rust eventually.