[Tutor] converting a source package into a dll/shared library?

[Duncan Gibson]

I asked:
> 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.

Kent suggested:
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>
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.
    Duncan