<p dir="ltr">At a glance, all of these sound like good modernizing enhancements for cprofile. It just takes someone to contribute the work. :)</p>
<br><div class="gmail_quote"><div dir="ltr">On Tue, Jan 10, 2017, 8:57 AM Ethan Furman <<a href="mailto:ethan@stoneleaf.us">ethan@stoneleaf.us</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 01/10/2017 08:36 AM, Thane Brimhall wrote:<br class="gmail_msg">
<br class="gmail_msg">
> Does anyone have thoughts on this topic? I assume the silence is because<br class="gmail_msg">
> this suggestion is too trivial to matter.<br class="gmail_msg">
<br class="gmail_msg">
Sometimes it's just a matter of timing. :)<br class="gmail_msg">
<br class="gmail_msg">
> I use cProfile a lot, and would like to suggest three backwards-compatible<br class="gmail_msg">
> improvements to the API.<br class="gmail_msg">
><br class="gmail_msg">
> 1: When using cProfile on a specific piece of code I often use the<br class="gmail_msg">
> enable() and disable() methods. It occurred to me that this would<br class="gmail_msg">
> be an obvious place to use a context manager.<br class="gmail_msg">
<br class="gmail_msg">
Absolutely.<br class="gmail_msg">
<br class="gmail_msg">
> 2: Enhance the `print_stats` method on Profile to accept more options<br class="gmail_msg">
> currently available only through the pstats.Stats class. For example,<br class="gmail_msg">
> strip_dirs could be a boolean argument, and limit could accept an int.<br class="gmail_msg">
> This would reduce the number of cases you'd need to use the more complex<br class="gmail_msg">
> API.<br class="gmail_msg">
<br class="gmail_msg">
I don't have much experience with cProfile, but this seems reasonable.<br class="gmail_msg">
<br class="gmail_msg">
> 3: I often forget which string keys are available for sorting. It would<br class="gmail_msg">
> be nice to add an enum for these so a user could have their linter and<br class="gmail_msg">
> IDE check that value pre-runtime. Since it would subclass `str` and<br class="gmail_msg">
> `Enum` it would still work with all currently existing code.<br class="gmail_msg">
<br class="gmail_msg">
Absolutely! :)<br class="gmail_msg">
<br class="gmail_msg">
> The current documentation contains the following code:<br class="gmail_msg">
><br class="gmail_msg">
> import cProfile, pstats, io<br class="gmail_msg">
> pr = cProfile.Profile()<br class="gmail_msg">
> pr.enable()<br class="gmail_msg">
> # ... do something ...<br class="gmail_msg">
> pr.disable()<br class="gmail_msg">
> s = io.StringIO()<br class="gmail_msg">
> sortby = 'cumulative'<br class="gmail_msg">
> ps = pstats.Stats(pr, stream=s).sort_stats(sortby)<br class="gmail_msg">
> ps.print_stats()<br class="gmail_msg">
> print(s.getvalue())<br class="gmail_msg">
><br class="gmail_msg">
> While the code below doesn't exactly match the functionality above (eg. not<br class="gmail_msg">
> using StringIO), I envision the context manager working like this, along<br class="gmail_msg">
> with some adjustments on how to get the stats from the profiler:<br class="gmail_msg">
><br class="gmail_msg">
> import cProfile, pstats<br class="gmail_msg">
> with cProfile.Profile() as pr:<br class="gmail_msg">
> # ... do something ...<br class="gmail_msg">
> pr.print_stats(sort=pstats.Sort.cumulative, limit=10, strip_dirs=True)<br class="gmail_msg">
><br class="gmail_msg">
> As you can see, the code is shorter and somewhat more self-documenting. The<br class="gmail_msg">
> best thing about these suggestions is that as far as I can tell they would<br class="gmail_msg">
> be backwards-compatible API additions.<br class="gmail_msg">
<br class="gmail_msg">
The `pr.print_stats... line should not be inside the `with` block unless you want to profile that part as well.<br class="gmail_msg">
<br class="gmail_msg">
These suggestions seem fairly uncontroversial. Have you opened an issue on the issue tracker?<br class="gmail_msg">
<br class="gmail_msg">
The fun part of the patch will be the C code, but a Python proof-of-concept would be useful.<br class="gmail_msg">
<br class="gmail_msg">
--<br class="gmail_msg">
~Ethan~<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
Python-ideas mailing list<br class="gmail_msg">
<a href="mailto:Python-ideas@python.org" class="gmail_msg" target="_blank">Python-ideas@python.org</a><br class="gmail_msg">
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" class="gmail_msg" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br class="gmail_msg">
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" class="gmail_msg" target="_blank">http://python.org/psf/codeofconduct/</a><br class="gmail_msg">
</blockquote></div>