🔒 node class for linked lists

[vagrant plume]

can someone what this does?

__slots__ = 'element', 'next'

the context is this is in a node class for a linked list. ive never seen this __slots__ thing

[stark condor]

@vagrant plume

Python help channel opened

Remember to:

• Ask your Python question, not if you can ask or if there's an expert who can help.
• Show a code sample as text (rather than a screenshot) and the error message, if you've got one.
• Explain what you expect to happen and what actually happens.

:warning: Do not pip install anything that isn't related to your question, especially if asked to over DMs.

Closes after a period of inactivity, or when you send !close.

[slate cloak]

https://stackoverflow.com/a/28059785

hate to be redirecting somewhere but this post explains it very well

[fallow hound]

slots basically pre-determines allowed attribute names

!e

class Foo:
    __slots__ = ['a', 'b']

    def __init__(self):
        self.c = 123

Foo()

[stark condor]

:x: Your 3.12 eval job has completed with return code 1.

001 | Traceback (most recent call last):
002 |   File "/home/main.py", line 7, in <module>
003 |     Foo()
004 |   File "/home/main.py", line 5, in __init__
005 |     self.c = 123
006 |     ^^^^^^
007 | AttributeError: 'Foo' object has no attribute 'c'

[fallow hound]

I'm not allowed to make an attribute named c here because slots doesn't have it

!e

class Foo:
    __slots__ = ['a', 'b', 'c']

    def __init__(self):
        self.c = 123

Foo()

[stark condor]

:warning: Your 3.12 eval job has completed with return code 0.

[No output]

[vagrant plume]

does it have anything to do with memory efficiency?

[vagrant plume]

i have something in my notes about that but im not sure it pretains to this or something else

ah ok

i also have something in here about dict for instanciated objects

[fallow hound]

read the link above that bones linked

it covers all of this

[vagrant plume]

ok thanks

[vagrant plume]

thanks i missed this somehow lol

do attributes in classes only store references?

is this the same for variables?

[fallow hound]

this is beyond what I know about the inner workings of python

[vagrant plume]

can i show u an example of something i was testing?

[fallow hound]

sure

[vagrant plume]

so i tried referencing a immutable and mutable object and i did not expect this to happen and im not sure why it did

can i do !e inside a python snipet?

!e

class MyClass:
    def __init__(self, value):
        self.attribute = value

obj1 = MyClass(10)
obj2 = obj1

obj2.attribute = 20

print(obj1.attribute)
print(obj2.attribute)

[stark condor]

:white_check_mark: Your 3.12 eval job has completed with return code 0.

001 | 20
002 | 20

[vagrant plume]

mutable object:

!e

class MyClass:
    def __init__(self, value):
        self.attribute = value

obj1 = MyClass([1, 2, 3])
obj2 = obj1

obj1.attribute.append(4)

print(obj1.attribute)
print(obj2.attribute)

[fallow hound]

you're not sure why this is the outcome?

[stark condor]

:white_check_mark: Your 3.12 eval job has completed with return code 0.

001 | [1, 2, 3, 4]
002 | [1, 2, 3, 4]

[vagrant plume]

so when the object is mutable, changing obj1 also changes obj2

but when its immutable it doesnt?

[fallow hound]

obj1 and obj2 are always mutable here

[vagrant plume]

does that mean theres a new obj created?

[fallow hound]

the attribute being mutable is irrelevant

obj1 = MyClass(10)
obj2 = obj1

you now have 2 variables referencing the same object

this will never make a copy of the object

[vagrant plume]

obj1 = MyClass([1, 2, 3])
obj2 = obj1

obj1.attribute.append(4)

yeah but here the objs have different attribute even though they're referencing the same object?

wait sorry

this one has the same attribute

[vagrant plume]

this one does not

[fallow hound]

it doesn't matter, the class instance is already the same object

obj1 and obj2 are the same object

so it doesn't matter which variable you use to access the object to modify it

it's the same object

[vagrant plume]

oh wait it doesnt wtf

sorry

i confused myself

[fallow hound]

mutable attribute is not relevant here

[vagrant plume]

yeah my bad i thought i saw a different output

so mutability has nothing to do with how objects are referenced?

[fallow hound]

that's not what I said

I said in your example, the mutable attribute not irrelevant because you were doubling up on the instance of MyClass

[vagrant plume]

yeah sorry i get that im just asking a follow up question

[fallow hound]

it does because immutable objects can share memory

x = 'abc'
y = 'abc'

even though I'm creating two string literals, they are the same object

!e

x = 'abc'
y = 'abc'

print(id(x))
print(id(y))

[stark condor]

:white_check_mark: Your 3.12 eval job has completed with return code 0.

001 | 139772281527104
002 | 139772281527104

[fallow hound]

!e

x = []
y = []

print(id(x))
print(id(y))

[stark condor]

:white_check_mark: Your 3.12 eval job has completed with return code 0.

001 | 139855865727424
002 | 139855865729280

[fallow hound]

this would not happen if they were mutable

[vagrant plume]

oh thats so weird

[fallow hound]

why is it weird? Unique mutable objects need their own memory

but there's no advantage to immutable objects having unique memory

[vagrant plume]

thats true yeah

so the only bearing this has with attributes in a class is that if an attribute is a reference to a mutable object changing it is just a matter or changing the contents of the object where as changing an immutable object that a class attribute is referencing is a matter changing the reference to a completely new object

[fallow hound]

the issue you might run into (or it might be desired behaviour) is that unique instances can share the same attribute object reference

[stark condor]

Python help channel closed

This help channel has been closed and it's no longer possible to send messages here. If your question wasn't answered, feel free to create a new post in #1035199133436354600. To maximize your chances of getting a response, check out this guide on asking good questions.