Description
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 readablestr()
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:
- Add a method
TO.pprint(linebreak: bool=False, indent: int=2)
. This will returnClassName(argname=value, …)
. Whenlinebreak
isTrue
it will givef'ClassName(\n{indent*" "}argname=value,\n{indent*" "}…)'
, so making it something like pythons built-inpprint
for dicts. I think this should be rather straight forward. only thing that could make trouble is attributes with list-values … - Make
TgO.__repr__
useTgO.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 - Depending on the decision in 2., we could drop
TgO.__str__
, which would then fallback toTgO.__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 …