[issue32017] profile.Profile() has no method enable()
New submission from Antoine Pitrou <pitrou@free.fr>: The section here is wrong as it claims that API is common to profile and cProfile. https://docs.python.org/3/library/profile.html#module-cProfile ---------- assignee: docs@python components: Documentation messages: 306169 nosy: docs@python, eric.araujo, ezio.melotti, pitrou, willingc priority: normal severity: normal status: open title: profile.Profile() has no method enable() type: behavior versions: Python 3.6, Python 3.7 _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue32017> _______________________________________
Cheryl Sabella <chekat2@gmail.com> added the comment: I started taking a look at this and discovered a few things. There are four methods in the C module `_lsprof` that are within the Profiler class - `enable`, `disable`, `getstats`, and `clear` and which are all available through cProfile.Profile. These aren't available in profile.py. Also, `getstats` and `clear` aren't in the documentation and `enable` takes two optional parameters that aren't mentioned in the documentation. There are also many methods in profile.py that aren't documented. What would be the preferred approach to fixing the documentation? It seems that the documentation currently focuses on trying to make profile and cProfile as similar as possible. Should they have separate sections that define the differences? Or should `enable` and `disable` be removed since they aren't in profile? The example under https://docs.python.org/3.8/library/profile.html#profile.Profile uses `enable` and `disable` and seems to be a helpful example. ---------- nosy: +csabella stage: -> needs patch versions: +Python 3.8 _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue32017> _______________________________________
Antoine Pitrou <pitrou@free.fr> added the comment: We can't remove public-looking methods (i.e. they don't start with an underscore) like that because some people may be using them. Rather than document the differences, I think it would be more useful to try to bridge the gap by augmenting the profile API with whatever supplementary APIs cProfile has. If some API is difficult to implement for profile, then we can revisit that goal and make an exception. ---------- _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue32017> _______________________________________
bbayles <bbayles@gmail.com> added the comment: I'm afraid that profile.Profile and cProfile.Profile behave pretty differently, and there's not a good way to bring the methods from the C version to the Python version. The example at [1] shows a cProfile.Profile object being instantiated and enabled. At this point the profiler is tracing execution - until the disable() method is called, any activity is recorded. profile.Profile doesn't work this way. Creating a profile.Profile object doesn't cause activity to be recorded. It doesn't do anything until you call one of its run* methods. This is because the C version uses PyEval_SetProfile ([2]) to take advantage of CPython's "low-level support for attaching profiling and execution tracing facilities" ([3]). I don't think we can do that from the Python version. There is already a precedent for showing differences between cProfile.Profile and profile.Profile in the existing docs - see [4]. [1] https://docs.python.org/3/library/profile.html#profile.Profile [2] https://github.com/python/cpython/blob/6f0eb93183519024cb360162bdd81b9faec97... [3] https://docs.python.org/3/c-api/init.html#profiling-and-tracing [4] https://docs.python.org/3/library/profile.html#using-a-custom-timer ---------- nosy: +bbayles _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue32017> _______________________________________
Change by bbayles <bbayles@gmail.com>: ---------- keywords: +patch pull_requests: +5659 stage: needs patch -> patch review _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue32017> _______________________________________
bbayles <bbayles@gmail.com> added the comment: I've made a pull request that clarifies things in the docs. As csabella notes, there are some more differences that could be pointed out. The 'subcalls' and 'builtins' arguments could be explained as well. Nonetheless, I think the PR does fix some definitely incorrect aspects of the existing documentation and is at least an improvement. ---------- _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue32017> _______________________________________
participants (3)
-
Antoine Pitrou
-
bbayles
-
Cheryl Sabella