[Tutor] converting a source package into a dll/shared library?
duncan at thermal.esa.int
Wed Aug 15 10:41:44 CEST 2007
> Is it possible to convert a Python package, with __init__.py and
> related python modules, into a single DLL or shared library that can
> be imported in the same way?
> We have used py2exe and cx_freeze to create a complete executable,
> but we are curious whether there is a middle way between this single
> executable and distributing all of the source files.
K> You can get a modest degree of obscurity by distributing the .pyc
K> bytecode files instead of the .py source. These can still be
K> decompiled and reverse engineered but it is more effort.
Yes we really just want to protect ourselves from giving code
relating to various companies' products to their competitors,
even though we wrote the code ourselves based on the behaviour
of our own test input files for their tools. We don't want any
company to feel that we have exposed any internal details about
how their tools might work.
We had already found the py_compile and compileall modules,
and had even gone one further than .pyc files to create .pyo
files because these have no docstrings either. We also found
the dis module, but it is unlikely that anyone will to go to
all the effort to disassemble and reverse engineer the code.
K> I suppose you could rewrite some or all of the code into the Python
K> dialect supported by Pyrex and compile it that way.
That's something to remember for the future, but we already
have 100K lines of code for the 6 different tool formats that
we currently handle, so it would be non-trivial to change now.
Alan also suggested:
A> Since you refer to DLLs I'll assume a Windoze platform.
A> If so the answer is yes you can create an ActiveX/COM object.
A> So if its accessibility to non Python code you are interested
A> in grab a copy of Mark Hammonds Win32 book for details
A> and examples. You can even go DCOM if thats significant.
It's a demonstrator project, so we've written the whole thing
in Python for the rapid development side, and so far we have
not had to worry about accessing non-Python code.
Each company only needs to see how we've mapped their own tool
formats into our neutral format. Actual integration in their
non-Python code will be a completely different story involving
an alternate code generator spitting out C/C++...
Thanks for confirming our ideas and the extra feedback.
More information about the Tutor