Then again, if we need that, we can alsways call id(tg_object)

But this just returns a number, thats not helpful at all when I want to know the type of the object. Did you mean type?

proposal

I like that idea, good to read while making clear its not a dict. And we can just let it fall back to repr, I would be fine with that.

breaking

no. its not.

Then again, if we need that, we can alsways call id(tg_object)

But this just returns a number, thats not helpful at all when I want to know the type of the object. Did you mean type?

No, I mean that there are some cases like [object_1, object_2], where both are of the same type and have the same attribute values and you need to know if object_1 is object_2. In that case a representation like <TGObject at …> immediately gives the desired information. This info would be lost by prettyfying the representation, but if needed can be recovered by printing [id(object_1), id(object_2)].

oh, I see. They should just use an if clause then smh

Just a quick thought: v14 will drop py3.6, which means we can start using dataclasses at some point. dataclasses come with built-in support to print objects as ClassName(argname=value, …). And for py3.10+, the pprint module natively supports dataclasses as well, which would cover line breaks and indents. So we could

• wait with a custom __repr__ until we use dataclasses
• wait with a pprint method until we drop support for py3.9
• do a custom __repr__ manually for now and replace it with the dataclass-builtin method once we use dataclasses
• do a custom pprint manually for now/don't do it for now and replace it with the pprint module once we drop py3.9
• do everything manually for ever :)

Haven't thought yet about which options I like best, just putting this here for reference

Edit: py3.9 reaches EOL ~October 2025

Another idea: Instead of waiting for py3.10 to happen, we could just borrow the code from https://github.com/python/cpython/blob/3.10/Lib/pprint.py. See also python/cpython#24389. If we do this, we should double check how this works out with licenses, how we need to achknowledge python etc

so you want to override pprint in our library? Or how would you borrow it?

@Poolitzer Not really override, rather use a vendored version instead. But for it's just an idea. Noam also pointed out the pprint36 library. Maybe it's worth asking if they want to update to 3.10

okay. but vendoring it means the linebreaks and indention for dataclasses will only be shown whent he user uses pprint, and not print (which means one import more). So vendoring pprint or using pprint36 if they update to 3.10 means the dataclass representation will look a bit nicer automatically, if the user uses pprint.

I would argue thats not on us. The user can decide to do that, or to use 3.10. I think prints are often used as fast debug statements, so its not important that it looks perfect, it should just show everything needed.

So I will say that converting the objects to dataclasses is enough. We can add a note in the docs somewhere saying how to make the representation look even better.

I thinks we're talking past each other. The original intention of this issue was to improve the __str__ and __repr__ methods of TelegramObject and maybe add a method TO.prrint (or other naming) that behaves like the built in pprint but doesn't necessarily use the built in pprint.

Now my ideas was that if we convert everything to data classes anyway, we could leverage that for this issue. Vendoring pprint from 3.10 or using an updated version of pprint36 would be solely implementation detail of TO.pprint/__str__/__repr__.

Converting to dataclass ofc has the positive side effect that in py 3.10+ the built in pprint works well on TO. But the main point of this issue is to provide helpful string representations of TO independent of how TO is implemented

Okay. But the converting of all objects to data classes already improves the representation, no?

Right, I didn't put that correctly. Still, how exactly we get __repr__ to do what we want should be considered implementation detail IMO. If dataclasses do that for use, that's convenient, but if we decide against dataclasses or drop them at some point, we should still make sure that str(tg_object) gives something that is useful.

Having a method to.pprint as shortcut for py310.pprint(to) is still a nice touch IMO - at least until py3.9 reaches EOL.

alright, I can agree to that. I see that you switched stages, so nothing imminent anyway, and we can discuss the implementation detail once we get to the stage

Closed by #3234