I assume that this is the upstream issue:

https://bugreports.qt.io/browse/QTBUG-85546

I also posted to the PyQt5 mailing list about this. I'll update this if I get more information.

I noticed that there is a StackOverflow post about this:

https://stackoverflow.com/questions/64833558/apps-not-popping-up-on-macos-big-sur-11-0-1/64847505#64847505

After some investigation, it looks like importing matplotlib.backends._tkagg for some reason fixes things:

from matplotlib.backends import _tkagg
import matplotlib.pyplot as plt
fig = plt.figure()
assert 'QTAgg' in fig.canvas.__class__.__name__

It looks like that's a compiled module, I'll see if it sets some system-level stuff to make itself work. Maybe that's what we need to do for PyQt5 on Big Sur...

Actually importing tkinter or _tkinter (the C .so that import tkinter imports) is enough:

import _tkinter
import matplotlib.pyplot as plt
fig = plt.figure()
assert 'QTAgg' in fig.canvas.__class__.__name__

So I guess there is some magic in here?

https://github.com/python/cpython/blob/a26215db11cfcf7b5f55cab9e91396761a0e0bcf/Modules/_tkinter.c#L3465-L3646

EDIT: I'm guessing it's the inputhook or TCL code somehow, but this is too low-level for me personally to know.

Based on seeing in one of the linked issues that the SDK will give conflicting answers based on who it thinks is asking. My guess is that loading tk forces the SDK in to "old" mode which gives back qt an answer that it likes. If that is the case so level of PRE_LOAD would also "fix" the problem.

A suitable workaround seems to be QT_MAC_WANTS_LAYER=1, found on the PyQt5 mailing list via https://stackoverflow.com/questions/64818879/is-there-any-solution-regarding-to-pyqt-library-doesnt-work-in-mac-os-big-sur/64856281 and https://forums.macrumors.com/threads/pyqt5-and-big-sur.2260773/?post=29243620#post-29243620

Given that this seems to be generic to pyqt, I don't think we have to do anything about this right now, but leaving open as a signpost.

I was also told on the PyQt5 mailing list that 5.15.2 will have this QT_MAC_WANTS_LAYER on by default. But that won't help people with previous versions...

I don't think we have to do anything about this right now, but leaving open as a signpost.

Agreed it's not really matplotlib's problem. However, one option to try to save people some pain would be to add a platform.mac_ver() + os.getenv('QT_MAC_WANTS_LAYER') check in the PyQt5 backend, and warn people. This seems like an easy backport to the current maintained branches. The only real downside I see (other than it adding a handful of lines and the associated, hopefully low maintenance burden) is that this runs the risk of warning people who don't need to be warned if it turns out not to be a universal problem. To me the benefit it would bring to people who have their interpreter inexplicably hang would be worth this, but that's easy for me to say since I wouldn't be the one maintaining the new mpl lines :)

I'm struggling to reproduce this issue. I have these versions installed:

# Name                    Version                   Build  Channel
pyqt                      5.9.2            py39h23ab428_6  
qt                        5.9.7                h468cd18_1  

and the following script is working fine for me, on macos 11.1:

import matplotlib
matplotlib.use('QT5Agg')
import matplotlib.pyplot as plt

plt.figure()
plt.show()

and just to be sure, I've checked that echo $QT_MAC_WANTS_LAYER doesn't print anything. Any ideas if there's something else I need to be doing to reproduce the bug?

I never went as far back as 5.9 in the Qt versions. Doing some installs locally it looks like there is no problem on 5.11.3 (as far back as I could go with my Python 3.8 install using pip) but on 5.12.3 or above I can reproduce the issue with your snippet.

The conda packaged versions of Qt are getting painfully old these days...

😆 well I seem to get a different error with 5.12.2 (will open a new issue), but I can confirm this with 5.15.1

Huh, now I've re-installed 5.12.2 it seems to be working fine.

I think this is closed by #19334? If anyone disagrees please leave a comment or re-open.