on Windows (10 or 11) I get this error permanently by running the simple script
import wx
this just loads the Gui wxPython version 3.12 beta
at the end it takes 1 or 2 secs and the error comes up
(running the script in IDLE no error is displayed, nice)
any idea
Based on the info presented, I believe the following is likely. If you run test_test.py with IDLE, IDLE runs that under supervision of idlelib.run run with subprocess.open. Your test_test runs the import in a third process with subprocess.run and reports the error return code. There is no error in test_test so its return code is 0.
sorry for the presentation (test.py is just the mentioned one liner import wx)
Microsoft Windows [Version 10.0.19045.3930]
(c) Microsoft Corporation. All rights reserved.
C:\Users\Me>cd C:\Users\Me\Documents\Programming\Python\Mylib\experimental\test
C:\Users\Me\Documents\Programming\Python\Mylib\experimental\test>python
Python 3.12.1 (tags/v3.12.1:2305ca5, Dec 7 2023, 22:03:25) [MSC v.1937 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> print(subprocess.run(['python', 'test.py']).returncode)
3221225477
>>>
never use an IDE when chasing bugs, especially not if you think the IDE itself is buggy
>>> import wx
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
import wx
ModuleNotFoundError: No module named 'wx'
>>> import subprocess
>>> print(subprocess.run(['py', '-c', 'import wx']).returncode)
Traceback (most recent call last):
File "<string>", line 1, in <module>
import wx
ModuleNotFoundError: No module named 'wx'
1
The returncode for an import ModuleNotFoundError is 1.
After starting IDLE in Command Prompt with the same binary in my git repository with >python -m idlelib, I get the same output, except that the traceback from the subsubprocess appears in Command Prompt instead of Shell, as is documented. When wx is present but buggy, I would expect that IDLE should display the other return code if run in the proper manner. But this a a side issue relative to why the wx import fails.
that’s all very well what you are saying but my ulterior motive centred on the assumption that it is a legacy bug in the extension to wx and as such given the fact that Microsoft has changed the .dll behaviour some time ago
why does it come up so predictable at the change from 3.11 to 3.12
I actually thought somebody might hint to a relevant change in that update (sort of shortcut, although @barry-scott’s remark was a real pleasure, at least to me )