GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | ||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | ||||||
GeezerVison is showing github.com — gh-142186: all-local PEP-669 events by P403n1x87 · Pull Request #146182 · python/cpython Conversation
|
|
@markshannon apologies for pinging you again, I appreciate you might be busy with other work. I would love for this to land in main before the first beta in May if possible 🙏 |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
Overall, this looks good in terms of semantics and capabilities. I do have a problem with the naming, though. If we make all events "local", that does make the term "local" rather meaningless and terminology you use such as "instrumented local events" and "non-instrumented local events" is a bit opaque. Also, there is still a clear distinction between the events that can be precisely disabled and those that can only be disabled per code object. So, with that in mind, I think we should still keep the terms "global" and "local" for the events they apply to now, and merely frame the change as "global events can now be turned on and disable on a per-code object basis". In the docs, change "All local events can be disabled" to "All local events can be disabled per location" It is unfortunate the functions Sorry for taking so long to get back to this. It will get into 3.15 |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
@markshannon many thanks for your review.
I totally agree with this sentiment, however a feature like the low-impact monitoring API sits quite close to the "stripped wires" that it becomes tricky to avoid that. However
so as requested I have made some changes to the wording in the documentation and comments to try and capture this instead. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
This turned out to be a nice improvement. The code looks good. Thanks for doing this. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
@markshannon that's the "what's new" entry added. Thanks for your feedback and help with this 🙇 |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
Excellent. Thanks once again |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
…isableable (pythonGH-146182) * Make the `PY_UNWIND` monitoring event available as a code-local event to allow trapping on function exit events when an exception bubbles up. This complements the PY_RETURN event by allowing to catch any function exit event. * Allow `PY_UNWIND` to be `DISABLE`d; disabling it disables the event for the whole code object. * Do the above for `PY_THROW`, `RAISE`, `EXCEPTION_HANDLED`, and `RERAISE` events.
…RING_EVENT_*` values from pythongh-146182 (pythongh-148955) python#146182 left an unintended change in the `PY_MONITORING_*` macro values. This change reverts that part to avoid a user visible impact.
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
There was an error while loading. Please reload this page.