[Python-ideas] api suggestions for the cProfile module
Thane Brimhall
thane.brimhall at gmail.com
Tue Jan 10 12:16:52 EST 2017
Thanks for getting back to me on this! Yes timing can be a big factor. :)
Turns out this gave me opportunity to look a little further back in the
archives and someone suggested a very similar API change in November, so
maybe more people than just me would want a feature like this.
Good call on putting the print_stats outside of the context block. Kinda
meta to profile the profiler...
If the next step is to open an issue on the tracker, I'll do that. I can
work on a Python proof-of-concept to attach there as well.
Again, thanks for your feedback!
/Thane
On Tuesday, January 10, 2017 at 9:57:54 AM UTC-7, Ethan Furman wrote:
>
> On 01/10/2017 08:36 AM, Thane Brimhall wrote:
>
> > Does anyone have thoughts on this topic? I assume the silence is because
> > this suggestion is too trivial to matter.
>
> Sometimes it's just a matter of timing. :)
>
> > I use cProfile a lot, and would like to suggest three
> backwards-compatible
> > improvements to the API.
> >
> > 1: When using cProfile on a specific piece of code I often use the
> > enable() and disable() methods. It occurred to me that this would
> > be an obvious place to use a context manager.
>
> Absolutely.
>
> > 2: Enhance the `print_stats` method on Profile to accept more options
> > currently available only through the pstats.Stats class. For example,
> > strip_dirs could be a boolean argument, and limit could accept an int.
> > This would reduce the number of cases you'd need to use the more
> complex
> > API.
>
> I don't have much experience with cProfile, but this seems reasonable.
>
> > 3: I often forget which string keys are available for sorting. It would
> > be nice to add an enum for these so a user could have their linter and
> > IDE check that value pre-runtime. Since it would subclass `str` and
> > `Enum` it would still work with all currently existing code.
>
> Absolutely! :)
>
> > The current documentation contains the following code:
> >
> > import cProfile, pstats, io
> > pr = cProfile.Profile()
> > pr.enable()
> > # ... do something ...
> > pr.disable()
> > s = io.StringIO()
> > sortby = 'cumulative'
> > ps = pstats.Stats(pr, stream=s).sort_stats(sortby)
> > ps.print_stats()
> > print(s.getvalue())
> >
> > While the code below doesn't exactly match the functionality above (eg.
> not
> > using StringIO), I envision the context manager working like this,
> along
> > with some adjustments on how to get the stats from the profiler:
> >
> > import cProfile, pstats
> > with cProfile.Profile() as pr:
> > # ... do something ...
> > pr.print_stats(sort=pstats.Sort.cumulative, limit=10,
> strip_dirs=True)
> >
> > As you can see, the code is shorter and somewhat more self-documenting.
> The
> > best thing about these suggestions is that as far as I can tell they
> would
> > be backwards-compatible API additions.
>
> The `pr.print_stats... line should not be inside the `with` block unless
> you want to profile that part as well.
>
> These suggestions seem fairly uncontroversial. Have you opened an issue
> on the issue tracker?
>
> The fun part of the patch will be the C code, but a Python
> proof-of-concept would be useful.
>
> --
> ~Ethan~
> _______________________________________________
> Python-ideas mailing list
> Python... at python.org <javascript:>
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20170110/c4da4998/attachment.html>
More information about the Python-ideas
mailing list