The interception of Python and C functions is achieved through the `sys` module - however, when using thread locks from `threading` module for instance under context managers, the calls on the lock to `acquire()` and `release()` cannot be witnessed. If these methods were to be called explicitly then this is no problem.

The sys.setprofile() doc don't make it clear whether the __enter__ and __exit__ call were intended to be traceable events.  The docs do state, "there is no way for the profiler to know about context switches between threads, so it does not make sense to use this in the presence of multiple threads."

Thanks Raymond for the input.
So with some experimentation, the __enter__() & __exit__() functions could be traceable when other kinds of objects are used with the context manager (i.e with statement using file IO or custom class objects). However, just when the object is a Lock object, then this is not the case anymore - which basically shows an unusual behavior if we were to think that such statements are executed for a specific thread. Also please mind that the threading module already implements settrace() and setprofile() methods like the sys module to extend tracing capabilities.