Marc-Andre Lemburg added the comment: 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 ;-) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22438> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
