
<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 7 Jun 2017, at 20:06, Jim Baker <<a href="mailto:jim.baker@python.org" class="">jim.baker@python.org</a>> wrote:</div><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">Sorry, I wish this were true, but PyOpenSSL is not available on Jython, because we do not yet support CFFI for Jython. CFFI support is something we have looked at, but we have not implemented. (There is a related and far more ambitious project to implement support for the C Extension API,<span class="Apple-converted-space"> </span><a href="http://jyni.org/" target="_blank" class="">http://jyni.org/</a>, which Stefan Richthofer is working on with me under the Google Summer of Code.)</div></div></div></div></div></blockquote><div><br class=""></div><div>This is what I was worried about. Moving to require PyOpenSSL *also* locks us out of Jython support, at least for the time being. That’s another point in the “con” column for making PyOpenSSL a mandatory dependency.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote">I should mention that we sometimes see undocumented functionality leak out. For example,<span class="Apple-converted-space"> </span><a href="https://docs.python.org/3/library/socket.html#socket.socket.listen" class="">https://docs.python.org/3/library/socket.html#socket.socket.listen</a><span class="Apple-converted-space"> </span>doesn't say anything about backlog=0, but the requests test suite (last time I looked on Jython) now depends on it. We assumed it was something like<span class="Apple-converted-space"> </span><a href="http://pubs.opengroup.org/onlinepubs/009695399/functions/listen.html" class="">http://pubs.opengroup.org/onlinepubs/009695399/functions/listen.html</a>, but as described in<span class="Apple-converted-space"> </span><a href="http://bugs.python.org/issue8498" class="">http://bugs.python.org/issue8498</a>, it now means that "a server application in python that accepts exactly 1 connection", by passing to the underlying C. More tests, more docs, please, even though of course that's a lot of dev effort.<br class=""></div></div></div></div></blockquote></div><br class=""><div class="">Ah, yes, we do. In our defense, this is the semantic of the listen syscall, and the socket module is generally a pretty thin wrapper around most of the socket syscalls. But in hindsight this is definitely the kind of thing that gets tricky for someone trying to reimplement the socket module in terms of a different abstraction. I don’t want to dive down this rabbit hole because if we do I’ll have to start talking about how the complexity of the socket API is one of the other implementation hurdles for PEP 543, but I think that’s a conversation for another time.</div><div class=""><br class=""></div><div class="">Cory</div></body></html>