On 07.11.2014 11:52, Arfrever Frehtes Taifersar Arahesis wrote:
> 
> Arfrever Frehtes Taifersar Arahesis added the comment:
> 
>> No, the use of the underscore in _ssl is per convention that C
>> implementation part of stdlib modules are moved into modules that
>> start with an underscore. This doesn't mean that the APIs in
>> those modules are private, otherwise many C implementations we have
>> in the stdlib would be private :-)
> 
> The non-private C-implemented modules are these:
> 
> $ cd /usr/lib64/python2.7/lib-dynload ; echo [^_]*.so
> array.so audioop.so binascii.so bz2.so cmath.so cPickle.so crypt.so cStringIO.so datetime.so dbm.so fcntl.so future_builtins.so gdbm.so grp.so itertools.so linuxaudiodev.so math.so mmap.so nis.so operator.so ossaudiodev.so parser.so pyexpat.so readline.so resource.so select.so spwd.so strop.so syslog.so termios.so time.so unicodedata.so zlib.so
> 
> _[^_]-prefixed, undocumented modules (amongst whom are both _[^_].py and _[^_].so) should be treated as private modules for usage only by public modules in standard library.
> 
> (_winreg is the only _[^_]-prefixed, documented module in CPython 2.7.)

I think you're misunderstanding: just because an API is implemented
in one of the _module.c modules, doesn't imply that those APIs are
private. We have for a long time now used the approach to have a Python
module as main entry point and the _module.c modules providing the
C level bits needed by the Python module.

Regardless of whether the API can be considered private or not, packages
which have to monkey patch the low-level APIs in the network modules
will need access to those APIs in order to tap into the layers and
the sslwrap() function was/is such a low level API.

Also note that due to the major implementation changes in the ssl
module for 2.7.9 such quirks are actually expected and so it's good
that we are getting reports from eventlet and gevent on these
issues. After all, what use is a safer ssl module if your application
doesn't work anymore ;-)