Python does not play well with others

John Nagle nagle at animats.com
Fri Jan 26 05:43:35 CET 2007


Paul Rubin wrote:
> John Nagle <nagle at animats.com> writes:
> 
>>    That's the problem.  We now have four SSL implementations for
>>Python, none of which let you do all the things OpenSSL can do.
> 
> 
> I'm aware of some OpenSSL wrappers plus TLSlite.  Am I missing a
> couple more?  I guess maybe the OpenSSL wrappers also work on GnuTLS.
> 
> 
>>    Can you build the built-in SSL package without building all of
>>Python?  
> 
> 
> I thought there was no built-in SSL package-- it just calls OpenSSL.

     "import SSL" brings in a .dll or .so object called "_ssl.pyd".
This contains C glue code which connects Python to the
C-based OpenSSL library.  That's the component which needs work.
Its source code is at

   http://svn.python.org/view/python/trunk/Modules/_ssl.c

     Part of the problem is that the build of _ssl.pyd
is too integrated into the main Python build to work on easily.
You can't just build and test a new SSL module and give it to others
to test.  You have to rebuild the whole Python system, and
people who want to test the modified module need to run a
custom Python build.

     SSL is somewhat integrated into the socket module internally,
although from the code I don't see that this is absolutely
necessary.  The build machinery for SSL is in

   http://svn.python.org/view/python/trunk/setup.py

     After looking at that for a while, and the directory
structure, it looks like the Python directory layout and
build system makes the assumption that anything in the
standard distribution is built as part of the basic
Python build.  The module itself could be separated from
the trunk build; Python will run without it.   It's the
build process and directory structure which ties it up.

     As far as I can tell, there's no concept in the
Python build system of a module that's built separately
but ships with the standard Python distribution.  Is
that correct?

     So now I understand why the standard SSL module doesn't
get fixed, and why there are three or four alternative
re-implementations of it.  It's easier to replace than
to repair.

				John Nagle



More information about the Python-list mailing list