I have an application that uses WxPython 2.8. I had to compile the python sources to get python_d.lib/.dll/.exe for a Swig component I use.
But under the debug python I can no longer import wx ... here's what I get:
C:\vsm>python_d
Python 2.5.3a0 (release25-maint, Feb 4 2009, 14:28:31) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import wx
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\python25\lib\site-packages\wx-2.8-msw-unicode\wx\__init__.py", line 53, in <module>
from wx._core import *
File "C:\Python25\lib\site-packages\wx-2.8-msw-unicode\wx\_core.py", line 4, in <module>
import _core_
ImportError: No module named _core_
[70539 refs]
The _core_.pyd file does exist in the site_packages/wx-2.8-msw-unicode/wx directory.
I have an application that uses WxPython 2.8. I had to compile the python sources to get python_d.lib/.dll/.exe for a Swig component I use.
But under the debug python I can no longer import wx ... here's what I get:
C:\vsm>python_d
Python 2.5.3a0 (release25-maint, Feb 4 2009, 14:28:31) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import wx
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\python25\lib\site-packages\wx-2.8-msw-unicode\wx\__init__.py", line 53, in <module>
from wx._core import *
File "C:\Python25\lib\site-packages\wx-2.8-msw-unicode\wx\_core.py", line 4, in <module>
import _core_
ImportError: No module named _core_
[70539 refs]
The _core_.pyd file does exist in the site_packages/wx-2.8-msw-unicode/wx directory.
Has anyone experienced this before?
Thanks,
-S
________________
Using some Google-Fu, I found the following on the subject:
Where did you get the wxPython? If you went and compiled a debug build
of python -- won't it just load a debug build of wxPython? Did you
build it too? Wouldn't it be looking for _core_d.pyd? Just a guess.
I've never actually had a need to recompile Python or any binary
extensions (on Windows, at least)
--Stephen
···
On Wed, Feb 4, 2009 at 10:45 AM, Sandy Walsh <swalsh@impathnetworks.com> wrote:
Hi there,
Windows XP SP 3
Python 2.5
I have an application that uses WxPython 2.8. I had to compile the python
sources to get python_d.lib/.dll/.exe for a Swig component I use.
But under the debug python I can no longer import wx ... here's what I get:
I have an application that uses WxPython 2.8. I had to compile the python sources to get python_d.lib/.dll/.exe for a Swig component I use.
But under the debug python I can no longer import wx ... here's what I get:
C:\vsm>python_d
Python 2.5.3a0 (release25-maint, Feb 4 2009, 14:28:31) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import wx
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\python25\lib\site-packages\wx-2.8-msw-unicode\wx\__init__.py", line 53, in <module>
from wx._core import *
File "C:\Python25\lib\site-packages\wx-2.8-msw-unicode\wx\_core.py", line 4, in <module>
import _core_
ImportError: No module named _core_
[70539 refs]
The _core_.pyd file does exist in the site_packages/wx-2.8-msw-unicode/wx directory.
Has anyone experienced this before?
Thanks,
-S
Well, here's what the wxPython site gives for their reason to compile a dev version:
<quote>
If you have a need to compile other Python extension modules or applications that link with the /same version/ of the wxWidgets DLL that wxPython does, then you will want to get the development package. It includes a snapshot of the wx headers and the import libraries found on my system when I made the wxPython binaries.
</quote>
I'm pretty sure the other times I've seen this error on the list, it had to do with compiling their own Python and/or wxPython...
Mike: I found those same posts, but they don't really offer any suggestions for resolution.
Stephen, if it was looking for _core_d.pyd, shouldn't it be trying
import __core__d ?
No, because the importable module name from the Python perspective is still _core_. It is only the name of the physical file on disk that is _core_d.pyd.
That said, the wxpython I'm using is the standard, binary distribution.
Perhaps I do need to build a debug version of wxpython?
Can someone confirm that? Even better ... offer a rationale as to why?
This is unfortunate but is just how debug versions of Python work on Windows. Since different C runtime libraries are used, the debug and release versions of Python and the extension modules end up being not compatible with each other, so to avoid problems the debug Python will always add _d to the module name when it is looking for binary extension files. In other words, if you are going to use a debug Python then you must have debug versions of any of the binary extensions that you need to use.
It's been a long time since I've done this so I don't know if it's still doable, but one way around this issue is to rebuild Python and your other extension module in debug mode, but force the use of the release mode C Runtime Library. In other words, force it to use /MD instead of /MDd. That way the Python executable and DLL will be compatible with other 3rd party extension modules that you don't rebuild. There may be some tweaking you need to do in Python (maybe just setting a #define) to make it not add the _d to the module names when looking for extensions.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
This is unfortunate but is just how debug versions of Python work on Windows. Since different C runtime libraries are used, the debug and release versions of Python and the extension modules end up being not compatible with each other, so to avoid problems the debug Python will always add _d to the module name when it is looking for binary extension files. In other words, if you are going to use a debug Python then you must have debug versions of any of the binary extensions that you need to use.
It's been a long time since I've done this so I don't know if it's still doable, but one way around this issue is to rebuild Python and your other extension module in debug mode, but force the use of the release mode C Runtime Library. In other words, force it to use /MD instead of /MDd. That way the Python executable and DLL will be compatible with other 3rd party extension modules that you don't rebuild. There may be some tweaking you need to do in Python (maybe just setting a #define) to make it not add the _d to the module names when looking for extensions.
Thanks Robin,
Yes, this seems to be correct. As a test, I renamed __core__.pyd to __core__d.pyd and this gives the following error:
C:\vsm>python_d
Python 2.5.3a0 (release25-maint, Feb 4 2009, 14:28:31) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import wx
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\python25\lib\site-packages\wx-2.8-msw-unicode\wx\__init__.py", line 45, in <module>
from wx._core import *
ImportError: Module use of python25.dll conflicts with this version of Python.
[27904 refs]
I grabbed the devel srcs for wxpython, but there doesn't seem to be any process for building this into a debug package?
Am I missing something or is this opening a rats nest and I should just move along.
I grabbed the devel srcs for wxpython, but there doesn't seem to be any process for building this into a debug package?
Am I missing something or is this opening a rats nest and I should just move along.
It is a rats nest, but it's doable. Look in BUILD.txt for details, but basically you'll need to build a debug version of wxMSW and then when you build wxPython you need to specify the --debug flag.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
