This came up in church and my comment on it is too lengthy to post a question in dev chat, so here we go. Also this is not urgent in any way …

Current state

Currently str(tg_objec) will give str(tg_object.to_dict()) and repr(tg_object) will give somthing like <TGObject at …>.

The first one can be confusing for newbies as they might thing that tg_object is a dictionary and they will start using subscription instead of dot-notation and so on …

The second one has

• the downside that we don't know the content of the object
• the upside that while debugging we can easily differentiate different objects without seeing the whole blob of data. Then again, if we need that, we can alsways call id(tg_object).

Desired behavior

In view of above description, I think that it would be desirable to have a more helpful representation of TG Objects. We should keep in mind that

• __repr__ goal is to be unambiguous
• __str__ goal is to be readable
• str() calls __repr__, if __str__ is not defined

I think in our case "unambiguous" and "readable" largely collide. I.e. a representation of the form ClassName(argname=value, …) is both unambiguous and good to read. So this is what I propose we should do in detail:

Proposal:

1. Add a method TO.pprint(linebreak: bool=False, indent: int=2). This will return ClassName(argname=value, …). When linebreak is True it will give f'ClassName(\n{indent*" "}argname=value,\n{indent*" "}…)', so making it something like pythons built-in pprint for dicts. I think this should be rather straight forward. only thing that could make trouble is attributes with list-values …
2. Make TgO.__repr__ use TgO.pprint. Here we could argue, if you want to skip arguments that are not in _id_attrs, as _id_attrs alone can be argumed to be unambiguous. But I think we're better of just including everything
3. Depending on the decision in 2., we could drop TgO.__str__, which would then fallback to TgO.__repr__

Questions:

• What do you think of this?
• Would this change be big enough to consider it breaking? I wouldn't say so, but being safe also doesn't hurt …