Closed jmeickle closed 7 years ago
The two unrelated features should be split into separate pull requests.
The new code in show_graph() doesn't actually work (see the test failures in Travis).
Other than that, I'm in favour of both features. And yes, a redesign of the API to be more flexible would be nice to have too.
Can you rebase this PR to only contain one feature (the addition of growth
), make it work (fix tests), and make the docstring user-friendly (which will involve a large amount of duplication in argument names, I'm afraid)?
I've been using objgraph in my Python roguelike. Peak object count is interesting info, but show_growth() prints, which doesn't work when you're using curses to control the console. I added a growth() function which returns the data used in the table.
Not strictly related, but there's a second commit in here that lets you return the dot file as a string without writing it to disk or opening it, which lets me have more control over the results (like postprocessing, or piping the output to something).
I didn't have time to make further changes, but while working on the code I came up with a few suggestions:
printer
argument (falling back toprint
), and then callprinter()
in functions instead ofprint()
directly.show_growth()
could have an option for current as well as peak object count/delta. Or inshow_graph()
, functions likeobj_label
could be arguments that can be overridden. (An object-oriented equivalent that allows subclassing the render functions would be even better.)show_growth()
in function defaults isn't a great idea. How they work is poorly understood, and I suspect it'll lead to someone trying to use it as a 'reset', which doesn't work:A better option would be to store stats at the module level and add
reset=False
to relevant functions.Suggestions aside - thanks for all the great work on this! It's a really wonderful tool :) I wish I'd tried it sooner...