3.11 changed to 3.12 brought %errorlevel% -1073741819

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 :slightly_smiling_face:

3.12 beta? Use the released version of python 3.12, which is 3.12.1 at the moment.

How did you install wx?
How do you run the one line script?

via pip and there is only 3.12.1 (I think beta I have read somewhere or on PyPi it’s not released for 3.12)

in Geany the error comes up and I checked it with the .bat file

@echo off
python %1
echo.
echo the return code of  '%1'  is  %errorlevel%
echo.
pause

where %1 was the simple .py module containing the afore mentioned import

there are really two questions (at least to me)

  • where could the bug be in the extension to wx or in sip (I think people are already searching, may be a very old bug which did not surface)

  • why doesn’t it show up in IDLE or PyScriptor (may be they run it in a separate process)

the script as such seems to run perfect :worried:

By default, IDLE runs user code in a subprocess. I have no idea why that would make a difference.

well, if I run the test.py script containing that said single import as (test_test.py)

import subprocess
completed = subprocess.run(['python', 'test.py'])
print(f'completed: {completed.returncode}')

it gives

completed: 3221225477

the return code of  'test_test.py'  is  0

Press any key to continue . . .

may be I get something wrong but that IDLE does not show the error seems odd (at least to me :flushed:)

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 :rofl:

Apparently that means access violation in windows.
See DLL Crash on Exit with error 3221225477 - Microsoft Q&A

FYI On windows its easier to web search for exit codes in hex.

2 Likes

that is what I call real help, thank you :joy:
do you think I’m wrong that IDLE should bring up that error code (although I never use IDLE) :smirk:

Here is output from current 3.13.0a3+ REPL:

>>> 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 :joy:)