CPython is compiled with one of two unicode modes.  The symbols in the dynamic 
library are different based on that original configuration flag.  Basically 
that config flag on python makes versions of python that are binary 
incompatible with one another even though they are the same version.  Native 
python extensions that link against python, need to therefore be linked against 
one or the other.  You can't link against both simultaneously.

Since most CPython native extensions are either pre built for a linux 
distribution (under the control of a managed package system), or are built on 
the target system itself, this is not an issue.   They know which flags were 
used by the python on the system.  In windows land, which is primarily a binary 
distribution land in which there is no cohesive binary package system managing 
the dependencies, your only real choice for binary distributions is to build 
both and provide them both.

If you try to run a mismatched binary with python, it will error out at runtime 
saying it can't find symbols, or entry points.  This would potentially look 
much like the error you post.  Though I would expect to see a more specific 
error info.  But at its base level, it would have trouble finding the function 
it was looking for, due to the function being fundamentally different in the 
data type of the parameters.  The symbol it was looking for would not be found.

Though there could be a myriad of other reasons why its having trouble finding 
that symbol.

On Oct 27, 2011, at 11:16 PM, Max Slimmer wrote:

> I am running python 2.6 under windows and would like to access some .net 
> code. I have downloaded pythonnet-2.0-alpha2-136-py26.zip from source-forge. 
> I can run the python.exe in \python2.6-UCS2 folder and from there import clr, 
> however I want to import and run from my existing python2.6 installation. I 
> put the clr.pyd file in sitepackages and also in DLLs but when I get the 
> following:
> 
> Python 2.6.6 (r266:84297, Aug 24 2010, 18:46:32) [MSC v.1500 32 bit (Intel)] 
> on
> win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import clr
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> ImportError: dynamic module does not define init function (initclr)
> >>>
> 
> I also could use a bit more documentation, I went to Bryan Lloyd's blog and 
> see:
> Refactored import syntax: now you can use un-prefixed namespace names ( "from 
> System import *") instead of the old "magic CLR module" syntax ("from 
> CLR.System...). The old "CLR." syntax is still supported until 3.0, but now 
> officially deprecated. This was the main compatibility problem with code 
> targeted for IP.
> 
> I can't figure how to get here!  
> 
> what is the difference between the -UCS2 and -UCS4 folders?
> 
> 
> _________________________________________________
> Python.NET mailing list - PythonDotNet@python.org
> http://mail.python.org/mailman/listinfo/pythondotnet

_________________________________________________
Python.NET mailing list - PythonDotNet@python.org
http://mail.python.org/mailman/listinfo/pythondotnet

Reply via email to