Repository navigation
Implement PEP 799 – A dedicated profiling package for organizing Python profiling tools #138122
Description
Activity
Not sure if this is the best place to discuss the name, but I'm not sure if "tracing" is the best new name for
cProfile.First of all, I think it's a great idea to organize all of our profilers and make it a new place to host other kinds of profilers, but "tracing" actually has its own meaning (as far as I understand).
The more accurate concept against "sampling" is probably "deterministic" (and I know it's long and difficult to spell), which means we record at all function entries and exits.
"tracing" on the other hand, often implies that we have not only the accumulated data for function calls, but also the information of each call - so that we can visualize it on a timeline. If you google tracing profiler,
Perfettomight be one of the tools that catch your eyes - that's a real tracing tool (or chrome tracing which is its predecessor). VizTracer is a tracing profiler for Python. It generates a tracing graph, which looks like a flamegraph but it's not.cProfiledoes not have the capability. It can only accumulate data and summarize it. Calling it a tracing profiler might confuse people (and might take the position of an actual tracing profiler we want to add in the future).From another perpective,
cProfiledoes not usesys.settrace, which is another "trace" concept that exists in CPython already.Do you think we should come up with another name for
cProfilein the new package?Reacted by Sergey MiryanovNot sure if this is the best place to discuss the name, but I'm not sure if "tracing" is the best new name for cProfile.
First of all, I think it's a great idea to organize all of our profilers and make it a new place to host other kinds of profilers, but "tracing" actually has its own meaning (as far as I understand).
The more accurate concept against "sampling" is probably "deterministic" (and I know it's long and difficult to spell), which means we record at all function entries and exits.
"tracing" on the other hand, often implies that we have not only the accumulated data for function calls, but also the information of each call - so that we can visualize it on a timeline. If you google tracing profiler, Perfetto might be one of the tools that catch your eyes - that's a real tracing tool (or chrome tracing which is its predecessor). VizTracer is a tracing profiler for Python. It generates a tracing graph, which looks like a flamegraph but it's not.
cProfile does not have the capability. It can only accumulate data and summarize it. Calling it a tracing profiler might confuse people (and might take the position of an actual tracing profiler we want to add in the future).
From another perpective, cProfile does not use sys.settrace, which is another "trace" concept that exists in CPython already.
Do you think we should come up with another name for cProfile in the new package?
I completely understand your concerns about the naming, and thank you for taking the time to provide this detailed technical feedback. You make good points about the distinction between “tracing” and what cProfile actually does.
Although I kind of disagree I think you are also right that “tracing” can be ambiguous here and indeed it may imply that we are referring to timeline-based profiling that captures individual call information The potential confusion with sys.settrace is also a valid concern although I think it doesn't apply a lot here as is an implementation aspect in any case. But is an interesting point.
My personal opinion here is that although what you say is true the distinction is too nuanced to matter. Deterministic profiler is also not a great name IMHO as if we are a real pure tracing profiler that would also be deterministic, which would also be confusing.
I’m definitely open to considering this feedback and think it merits some discussion. The technical accuracy of our naming is important, both for clarity and to avoid blocking future actual tracing profiler implementations.
However, as you noted, the timing is challenging since PEP 799 has already been accepted, which would mean we’d need to go through the process of modifying the PEP if we decide to change the name. That said, getting the naming right is important enough that it may be worth that effort.
I think this needs input from the docs working group at least. We can keep the discussion here or maybe open another one in discuss. Do you have any preference?
Thanks for the ping @pablogsal.
Not sure if this is the best place to discuss the name, but I'm not sure if "tracing" is the best new name for cProfile.
...I completely understand your concerns about the naming, and thank you for taking the time to provide this detailed technical feedback. You make good points about the distinction between “tracing” and what cProfile actually does.
My personal opinion here is that although what you say is true the distinction is too nuanced to matter. Deterministic profiler is also not a great name IMHO as if we are a real pure tracing profiler that would also be deterministic, which would also be confusing.
From what I can see from a quick search,
tracing,instrumen{ted,ation},deterministic, andcall graphseem to be used as near-synonyms. This contrasts with sampling profiling, which seems to use the same term. There doesn't seem to be an obvious and consistent bright-line distinction I can find in third-party documents for what distinguishes a 'proper' tracing profiler.Although I kind of disagree I think you are also right that “tracing” can be ambiguous here and indeed it may imply that we are referring to timeline-based profiling that captures individual call information The potential confusion with sys.settrace is also a valid concern although I think it doesn't apply a lot here as is an implementation aspect in any case. But is an interesting point.
The technical accuracy of our naming is important, both for clarity and to avoid blocking future actual tracing profiler implementations.
If a future Python version implemented support for tracing profiling in the VizTracer/Perfetto form, would we still keep the current (
cProfile) implementation ofprofiling.tracing? A possible/likely scenario would be that we expose the higher fidelity information under the existingprofiling.tracingname, possibly with a compat layer. If so, I don't think there is a risk to using thetracingname now, as it doesn't prevent future improvements/features.A
I propose the name
profiling.boringfor cProfile.Reacted by Sergey Miryanov, Bartosz Sławecki and Asif Saif Uddin {"Auvi":"অভি"}I propose the name
profiling.boringfor cProfile.
Reacted by Sergey Miryanov, Stan Ulbrych, Maxim Martynov, An Long, Bartosz Sławecki, Savannah Ostrowski and Asif Saif Uddin {"Auvi":"অভি"}I think it's possible that people are not that familiar with tracers so they think tracers are very similar to profilers. From my point of view, a tracer is distinctly different than a profiler. A tracer can be used for profiling (or, as a profiler), but it normally provides much more detailed information.
OpenTelemetry is probably the most popular cross-language tracing framework. One of the core concepts is a "span", meaning an event with a start/end pair timestamp - which a profiler normally does not provide.
All the results from my search on Google for "tracing profiler" are some kinds of profiler(tool) that provides a real tracing capability(Android, Google Cloud, Perfetto, dotNet, torch, etc.). I did not find any counter-example with my limited efforts.
A tracer (tracing profiler) has its own limitation - because it records too much information, it has to compromise on either the functions it records, or the length of the program. So we can't replace
cProfilewith a tracing profiler likeVizTracer.In my opinion,
profiler.boringis a slightly better name thanprofiler.tracing:).What about a similar but more official name
profiler.basic?cProfileis not only instrumented, but also provides less information on the call frame compared to our new sampling profiler. It only has information of it caller (not the full frame).basicmight be a good name to drive people away from using it when they need more advanced features.Reacted by Asif Saif Uddin {"Auvi":"অভি"}a tracer is distinctly different than a profiler
In this case, would a (hypothetical) future stdlib tracing implementation be considered for the
profilingpackage/namespace?I would be
-1on a name likeprofiling.basic, because it doesn't describe what the profiler does, only what we have decided its capabilities are. As Pablo/PEP 799 said, there remain valid use cases for thecProfilebased implementation. I would also hope that in the future, we will have improvedprofiling.tracingto have more information such that is is no longer 'basic'.A
In this case, would a (hypothetical) future stdlib tracing implementation be considered for the
profilingpackage/namespace?Yes, I don't think is unreasonable
What about a similar but more official name
profiler.basic?Yeah I agree this is probably a suboptimal name because it looks like is a "worse" version by nature and doesn't imply the tradeoffs.
146 remaining items
- added 6 commits that reference this issue
on Feb 15, 2026 - added a commit that references this issue
on Mar 30, 2026 - added a commit that references this issue
on Mar 30, 2026 Triage: PEP has been marked as final, can this be closed as completed?
Issue to collect all PRs for the implementation of PEP-799
Linked PRs
profiling.samplingin the documentation (PEP 799) #138389Modules/_remote_debugging/module.c#143218