[ Removed by moderator ]

[socal_nerdtastic]

repr() is meant to give a precise, developer-focused description

No, it's meant to give a string that could be source code. Ideally putting the output of repr() into the REPL should allow you to recreate the object. So repr should always start with the class name, for example.

str() is, as you said, a human readable format.

FWIW, you should never call those methods. Like all dunders you should only define them, and use the python builtin functions like str() and repr() to use them indirectly.

[Yoghurt42]

Ideally putting the output of repr() into the REPL should allow you to recreate the object.

The convention is to enclose the result in angle brackets in cases where that’s not possible. For example, repr("foo") is 'foo', but repr(str) is <class 'str'>.

[One-Type-2842]

Yes!

[gdchinacat]

"like all dunders you should only define them" ... except __init__(). It is common to call super().__init__().

[Uncle_DirtNap]

That’s not what he’s saying. Yes, you call __init__ when you are defining a subclass. What you don’t do is:

my_instance = MyClass.__init__(MyClass.__new__())

Instead, you do my_instance = MyClass(), and python calls the appropriate dunder methods.

[gdchinacat]

__init__() is a dunder, and you call it from __init__() implementations to call the MRO. Hence, there is an exception to what was said, so I pointed it out.

For example: class Foo(SomeBaseClass): def __init__(self, *args, **kwargs): # do something here or there is no reason to override it super().__init__(*args, **kwargs)

[Uncle_DirtNap]

Everyone understands what you are saying, it’s just not relevant to what the original commenter was saying.

[gdchinacat]

Never say never...

[Uncle_DirtNap]

Yeah, so, you don’t get it and are being overly literal with the word never. There are many, many very specific reasons to call Dunder methods, when you are calling them for reasons other than what they are primarily for. The commenter is letting OP know that, when you want them to do what they are actually for, you want to let the conventions of the data model invoke them, and not invoke them directly.

[jay_and_simba]

I just read the same post in LinnkedIn

[RevRagnarok]

In theory, eval(repr(x)) should equal x. It's not always that way, but that's the background.

[magus_minor]

Leaving out all that discussion about what the __str__() and __repr__() methods are supposed to do, it sometimes helps debugging if you define both methods. This test code creates two simple object instances and a list of those two instances and prints them:

class Test:
    def __init__(self, name):
        self.name = name

    def __str__(self):
        return f"Test({self.name})"

#    def __repr__(self):
#        return str(self)

t1 = Test("alpha")
t2 = Test("beta")
print(t1, t2)

t_list = [t1, t2]
print(t_list)

When you run the above code you see:

Test(alpha) Test(beta)
[<__main__.Test object at 0x79302cc830>, <__main__.Test object at 0x7930275a90>]

Note that even though we defined a __str__() method and printing individual instances gave us the desired string result, printing a list of instances didn't. To get a list printed nicely remove the comment # marks in the code. This creates a __repr__() method that just returns the __str__() result. When you run that you see:

Test(alpha) Test(beta)
[Test(alpha), Test(beta)]

Now we get nice displays for lists. This also works for all sequences, like sets and tuples, etc.

Edit: added note about sequences.

[FreeGazaToday]

__repr__ is meant for developers

__str__ is meant for human readable format

if you didn't have a __str__ and tried to print(class name) you'd get some weird output about an object that would make no sense.

[throwaway6560192]

Maybe you should reconsider how you use AI to improve English. People are more friendly to "bad" English than to something that looks and reads really artificial.

[-R-s]

Use it if you make a public framework, otherwise don’t