On 29Mar.2019 2020, Inada Naoki wrote:
I don't like adding more Python callback from low level.
Python runtime is very complicated already, especially __del__, shutdown process, and multi threading. Python callback from low level is source of very difficult bugs always.
Asynchronous callbacks, sure. These are all synchronous and always as part of a Python operation while the GIL is held (I think putting them immediately after parameter validation is the best place, but am hesitant to make that a hard rule).
Additionally, if we used the PEP for logging complex application, the log will be unreliable.
I think "then don't do that" is a valid response here. There are plenty of ways to use Python features incorrectly and cause problems (I've diagnosed many of them :) ). This doesn't make that any more or less true.
- Want to open file A in C code, call callback.
- In the callback, "A is opened" is logged.
- In the same callback, import may be happened and logged.
- In the same callback, other thread may be run and any thing can be logged.
- Many many other things happens and callback is called.
- Then, open the file A.
In this example, logged event ordering and timing is very different from real event ordering and timing.
Yep. If you implement a bad hook then you get bad results. But at least the user can fix that themselves (since they caused it themselves).
I've already used these hooks for a number of useful purposes, and it isn't difficult to write one that works just fine.
I prefer low level tool to trace low level thing, although it lacks some application context. Maybe, DTrace will become more important tool.
See my other reply about this. DTrace on Windows is a very long way from being suitable for production environments.