Repository navigation
[MNT]: macosx event_loop_is_running is a deceptive name #32041
Description
Summary
The macosx backend has an event_loop_is_running method, documented as:
Return whether the macosx backend has set up the NSApp main event loop.
The method name is wrong, at least from the macOS perspective. The event loop is not running until a call to plt.show() or FigureCanvas.start_event_loop.
The documentation string is partially incorrect - the state of the event loop after we call lazy_init() is an implementation detail of NSApplication and PyOS_InputHook. It could still be "not set up" until the first call to CFRunLoopGet…().
Proposed fix
The method should probably be is_backend_initialized or something similar with a documentation string of:
Return whether the macosx backend has been initialized.
That said, event_loop_is_running needs to remain a method as it is being directly called by vispy's _detect_eventloop.py
Perhaps we should expose our _get_running_interactive_framework() as documented public API so other projects do not need to access backend internals?
Activity
joddeepesh-cloud commentedon Jul 18, 2026
Hi! I'd like to work on this issue. I'm currently investigating the implementation and the API usage to understand the proposed changes. If there are no objections, I'll prepare a PR based on the discussion here.
iccir commentedon Jul 18, 2026
PRs are always welcome! That said, I think that this issue needs a discussion from project maintainers about what the exact policy should be when another project is using backend internals. I'm also not sure about the exact process of introducing new API. I suspect that this would involve a deprecation cycle at least for the
event_loop_is_runningname.joddeepesh-cloud commentedon Jul 18, 2026
Thanks for the clarification! That makes sense. I'll hold off on proposing API changes until there's more guidance on the preferred direction and deprecation strategy. In the meantime, I'll continue exploring the codebase.
timhoffm commentedon Jul 22, 2026
While it may be technically ok to expose
_get_running_interactive_framework(), it's not really our responsibility to provide such a functionality. So I'm -0.5 on making this public. It's perfectly fine if vispy copies our implementation. Responsibility stays separated.On a broader note, IMHO vispy is working around an ipython deficit and what the'd really want is a function
get_ipython().running_in_notebook().Since
event_loop_is_running()is from the private_macosxmodule we formally could just rename, though we shouldn't consciously break vispy.What is feasible:
event_loop_is_running()an alias to the new methodget_ipython().running_in_notebook(). method. At least, they have to switch and version gate on the new method, possibly onrunning_in_notebook().If somebody wants to take that effort, go for it. Otherwise, it would be a minimal good step to just document the imprecise naming in the docstring of
event_loop_is_running().joddeepesh-cloud commentedon Jul 25, 2026
I'd be happy to work on the suggested docstring clarification for event_loop_is_running() if no one else is already doing it .
iccir commentedon Sep 12, 2026
I think
get_ipython().running_in_notebook()is covered by How to detect which frontends are connected.tacaswell's 2019 comment:
He later linked to our cbook code, which vispy then vendored. This body of this method will change in 3.12 to account for the new macOS backend. We will need to reach out to vispy regardless.