
What I mean is that a third party software vendor supplies a foobarapp.pyd and a foobarapp_d.pyd dlls that link to python2x.dll and python2x_d.dll respectively. But the latter will have been compiled to match a certain settings of the objimpl.h header, which may not match whatever is being used to build the local python2x_d.dll. And thus, you get strange and hard to debug linker errors when trying to load external libraries. When developing superapp.exe, which uses a custom build of python2x, perhaps even embedded, python2x_d.dll is used extensively both during the development process and the testing process. This is why foobarapp_d.pyd is necessary and why it is supplied by any sensible vendor providing opaque python extensions. But the current objimpl.h api makes it a matter of developer choice whether that foobarapp_d.pyd will successfully link with your python2x_d.dll or not. IMHO, it is not good practice to expose an API that changes depending on preprocessor settings like this. K
-----Original Message----- From: "Martin v. Löwis" [mailto:martin@v.loewis.de] Sent: 14. júní 2010 22:13 To: Kristján Valur Jónsson Cc: python-dev@python.org Subject: Re: [Python-Dev] debug and release python
Some external software comes with proprietary .pyd bindings.
Can you please explain what a "proprietary .pyd binding" is?
Do you mean they come with extension modules? If so, there is no chance of using them in debug mode, anyway, right? So what specifically is the problem?
Regards, Martin