dnspython

[jayvdb]

I am using cheap-repr for debugging of https://github.com/jayvdb/dns-cache , and the problem I am facing is that https://github.com/rthalley/dnspython has a bunch of classes with a useless repr, and they are deeply nested.

The main need for me is the "Answer" class from dns.resolver.Resolver.query().

I can get a slightly better result by using register_repr and returning x.__dict__, but then the response member is the same, and then if I use its __dict__, there is another layer (and that is where the IP addrs, which is what is the most interesting part of the answer).

It would be great if there was a 'recursive __dict__ repr' which could be easily used.

[alexmojaki]

Hi, thanks for opening an issue! This repo is a bit too obscure for most people.

Are you using snoop or birdseye, or are you just using the library directly?

The recursive __dict__ repr sounds like a reasonable idea, but it also seems like it could end up producing huge expensive reprs very easily.

Why not just register the classes you actually care about?

from cheap_repr import register_repr, cheap_repr

@register_repr(dns.Answer)
@register_repr(dns.Response)
@register_repr(dns.IPAddress)
def repr_attrs_dict(x, _helper):
    return f"{type(x).__name__}({cheap_repr(x.__dict__)})"

[jayvdb]

I am using cheap_repr directly , and in conjunction with vimist/logger-helper#4 I didnt know about snoop - I've tried others, including PySnooper, and they leave me doing as much new and ugly hacks as I was trying to avoiding by using them. I'll give snoop a go.

I have done similar to your sample there, and that solved the main problem of seeing the IP (what dns_cache users mostly care about), but then there are lots of other classes which are in my cache results that I need to dig into when debugging. You can get a rough size of the class tree by the module lists at https://github.com/rthalley/dnspython/tree/master/dns and https://github.com/rthalley/dnspython/tree/master/dns/rdtypes/IN as it has roughly one class per module. And I am sure new classes will be added with reckless abandon in each release.

So I started thinking about a more generic solution. And while it could produce large reprs, this project already has the concept of "Suppression of long reprs" :P That general approach could also be applied here. Also a recursive helper is just a helper - if it is going to go crazy, a max recursion level arg could restore sanity easily without needing custom code.

[alexmojaki]

OK. I'm happy to review a PR - this isn't something I'm going to do myself.