I will defer to wx experts on if this is a good idea or not technically, I have grave concerns about this conceptually.

pyplot has roughly two roles:

• provide the MATLAB like global state implicit plotting
• stand in for an application because once you show a GUI window you are a GUI application

With plt.show(block=False) we assume that someone somewhere else is running the event loop (typically the the command prompt) so the figures are live when the user is not typing or actively running code.

With plt.show(block=True) we are saying "no one else is running the GUI event loop so it might as well be us! We will stop when we run out of open windows no matter how long it takes!".

There is also plt.pause(N) which says "I'll show the windows and then wait at most N seconds before stopping the event loop and carrying on.

Taken together I think using plt.show(block=True) in a callback in a UI framework violates two conceptual aspects. First, plt.show(block=True) is assuming it is in charge of the event loop. the behavior of "oh, someone else has this, carry on" is more forgiving than "I'm inside an event loop I'M DOING TO RAISE". The second is that typically the body of a callback in a UI framework is expected to be fast (because it can not get to the next UI event until it finishes the last one and you do not want to lock up the UI).

See https://matplotlib.org/stable/users/explain/interactive_guide.html for more writing on this.

It is the case that Wx (and Qt) gives you a way to run a re-entrant event loop (so is the middle of processing a callback take a break and process other callbacks for a bit), I am not sure if this is general across all of the toolkits we support.

All of this taken together, I am not an favor of changing this behavior. Given the example, I assume this is part of a much bigger UI application I would strongly suggest you go down path of using the explicit API + full embedding, rather than pyplot, and manage your windows yourself.

I do not know what the other backends do in the analogous case. If they all do block in in the callback, then despite my concerns the behavior should match.

Thanks !
Using plt.pause(-1) or plt.ginput(n=-1,timeout=-1,show_clicks=False)
instead of plt.show() works fine (at least in wxagg backend).

FYI, my typical use case is detailed below:
I have a script that does some interactive processing

def process_interactive(file):
	(put vlines and hlines that act as draggable cursors with appropriate callbacks)
	plt.plot(x,y)
	plt.show()
	return someresults

if __name__=="__main__":
	for f in sys.argv[1:]
		print(process_interactive(f))

However, because most users are not comfortable with command line,
I wrote a simple wx.gui with drag/drop zone and excel like result sheet.
I therefore have the following callback

OnDropFiles(self, x, y, filenames):
	for f in filenames:
		res=self.process_interactive(evt.files) ## this needs to block any other event processing by the app
	self.excel_like_control.putresults(res)

(the design may be bad and it would maybe be better to execute the first script through subprocess)

I would suggest the small modification to be something like:

def process_interactive(file, *, blocking_function=None):
     if blocking_function is None:
          blocking_function = lambda : plt.show(block=True)
     ...
     # your code
    ...
    blocking_function()
    return stuff

so that way when you wrap it for the UI you can parameterize how to block to the context.