[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