You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
As of 3.12 _lsprof no longer calls _PyEval_SetProfile making sys.getprofile() useless with cProfile #130377
Starting in 3.12 with the addition of sys.monitoring, _lsprof, specifically in profiler_enable, no longer calls _PyEval_SetProfile.
Very specifically, this impacts previous functionality where python -m cProfile -m whatever would result in sys.setprofile() being called, and subsequently the whatever module could access the profiler object via sys.getprofile()
To my knowledge this is now completely impossible as sys.monitoring provides no meaningful way to access the profiler object.
In my particular use case, profiling could be enabled within the application, or if python -m cProfile was used, the existing profiler could be used allowing profiling to happen earlier than the enablement point of cProfile within the application.
This is not a bug. sys.getprofile gets the profile function from sys.setprofile, cProfile before 3.12 happened to use that specific utility for profiling. It switched to sys.monitoring mechanism after 3.12, so sys.getprofile won't get anything for cProfile. Yes they both have the word profile in it, but there's never a guarantee that they will always be related. cProfile documentation does not provide a way to get the profile object from CLI either. This is just something unsupported that happened to work before 3.12.
If you just want something equivalent to your current method (which is not 100% accurate, it's only guarantees that if cProfile is running, sys.getprofile() will be not None), you can do sys.monitoring.get_tool(sys.monitoring.PROFILER_ID) - that will return a string if cProfile is running.
Still, cProfile does not provide an official way to access it's profiler object in CLI mode, if you need that, that's a feature request.
this came from PR #103534 which quietly removed the test assertions checking sys.getprofile() == prof with no changelog note.
The real gap is that get_tool() gives you a string but no way to reach the object.
Since PEP 799 is accepted and profiling.tracing lands in 3.15, a small addition makes sense:
profiling.tracing.get_active() ->Profile|None
use_tool_id already guarantees one owner, so the object is right there in _lsprof. Worth a feature request against profiling.tracing. @gaogaotiantian@pablogsal, happy to draft a PR.
Activity
gaogaotiantian commentedon Feb 20, 2025
This is not a bug.
sys.getprofilegets the profile function fromsys.setprofile,cProfilebefore 3.12 happened to use that specific utility for profiling. It switched tosys.monitoringmechanism after 3.12, sosys.getprofilewon't get anything forcProfile. Yes they both have the wordprofilein it, but there's never a guarantee that they will always be related.cProfiledocumentation does not provide a way to get the profile object from CLI either. This is just something unsupported that happened to work before 3.12.If you just want something equivalent to your current method (which is not 100% accurate, it's only guarantees that if
cProfileis running,sys.getprofile()will be notNone), you can dosys.monitoring.get_tool(sys.monitoring.PROFILER_ID)- that will return a string if cProfile is running.Still, cProfile does not provide an official way to access it's profiler object in CLI mode, if you need that, that's a feature request.
BHUVANSH855 commentedon Oct 20, 2026
this came from PR #103534 which quietly removed the test assertions checking
sys.getprofile() == profwith no changelog note.The real gap is that
get_tool()gives you a string but no way to reach the object.Since PEP 799 is accepted and
profiling.tracinglands in 3.15, a small addition makes sense:use_tool_idalready guarantees one owner, so the object is right there in_lsprof. Worth a feature request againstprofiling.tracing.@gaogaotiantian @pablogsal, happy to draft a PR.