homepage

Thanks Louie.
I've adjusted the issue title, as I think the core RFE is that we'd like the following helper function to work exactly the same way as calling sys.setprofile directly:
 def setprofile_helper(f):
 sys.setprofile(f)
The following utility function can be used to demonstrate the current discrepancy:
 def profile_call(setprofile, call):
 pr = profile.Profile()
 setprofile(pr.dispatcher)
 try:
 call()
 finally:
 setprofile(None)
 return pr
Specifically:
```
>>> profile_call(sys.setprofile, lambda:print("Profiled!"))
Profiled!
<profile.Profile object at 0x7fb2265966d8>
>>> profile_call(setprofile_helper, lambda:print("Profiled!"))
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File "<stdin>", line 4, in profile_call
 File "<stdin>", line 2, in setprofile_helper
 File "/usr/lib64/python3.5/profile.py", line 209, in trace_dispatch_i
 if self.dispatch[event](self, frame, t):
 File "/usr/lib64/python3.5/profile.py", line 293, in trace_dispatch_return
 assert frame is self.cur[-2].f_back, ("Bad return", self.cur[-3])
AssertionError: ('Bad return', ('profile', 0, 'profiler'))
```
If we can figure out a way to do it reliably, the most desirable approach would be to make helper functions like the above "just work", perhaps by remembering the stack frame where the profiler was *defined*, and using that as the reference point to construct the synthetic stack the first time a trace dispatch occurs.
If that transparent-to-the-user approach doesn't appear to be feasible, an alternative would be to offer a new private method on Profile objects to adjust their synthetic stack by one level, as if `sys.setprofile` had been called *before* the call into the helper function.
That is, a profiler-aware alternative to the helper function above might look like:
 def profile_helper(pr):
 sys.setprofile(pr.dispatcher)
 pr._adjust_stack()
and that's then the approach that the `__enter__` method would use to implement context management support.
The advantage of the latter private option is that it wouldn't need to support arbitrary helper functions, just the specific implementation of `__enter__` for issue 9285.
In either case, I *don't* think changing the assertion is the right answer - instead, I think the internal profiler state needs to be adjusted so the assertion passes without modification.