As of 3.12 _lsprof no longer calls _PyEval_SetProfile making sys.getprofile() useless with cProfile

[sivel]

Bug report

Bug description:

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.

Something to the effect of:

p = sys.getprofile()
if p is None:
    p = cProfile.Profile()
    p.enable()

CPython versions tested on:

3.13

Operating systems tested on:

Linux

[gaogaotiantian]

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.