This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lemburg
Recipients Arfrever, Denis.Bilenko, alex, barry, benjamin.peterson, christian.heimes, dstufft, giampaolo.rodola, janssen, lemburg, pitrou
Date 2014-11-07.10:30:50
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <545C9F52.50909@egenix.com>
In-reply-to <1415355119.94.0.74501965021.issue22438@psf.upfronthosting.co.za>
Content
On 07.11.2014 11:12, Arfrever Frehtes Taifersar Arahesis wrote:
> 
> Arfrever Frehtes Taifersar Arahesis added the comment:
> 
> _ssl has leading underscore.
> Privateness is "inherited", so both A._B.C and A._B._D are private.

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 :-)

Also note that _ssl.sslwrap is special in that it's the main
interface between _ssl and ssl.

BTW: The sslwrap_simple() API was also removed in 2.7.9.

Note: Any libraries that need to monkey patch the Python
network stdlib will need access to these APIs. Given that the
ssl implementation changed a lot in 2.7.9, I think special care
has to be taken not to break too many of these. Using gevent
and eventlet as test cases for whether backwards compatibility
is good enough sounds like a workable approach, IMO.
History
Date User Action Args
2014-11-07 10:30:51lemburgsetrecipients: + lemburg, barry, janssen, pitrou, giampaolo.rodola, christian.heimes, benjamin.peterson, Arfrever, alex, Denis.Bilenko, dstufft
2014-11-07 10:30:51lemburglinkissue22438 messages
2014-11-07 10:30:50lemburgcreate