> On 7 Jun 2017, at 20:06, Jim Baker <jim.ba...@python.org> wrote:
>
> 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,
> http://jyni.org/ <http://jyni.org/>, which Stefan Richthofer is working on
> with me under the Google Summer of Code.)
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.
> I should mention that we sometimes see undocumented functionality leak out.
> For example,
> https://docs.python.org/3/library/socket.html#socket.socket.listen
> <https://docs.python.org/3/library/socket.html#socket.socket.listen> 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
> http://pubs.opengroup.org/onlinepubs/009695399/functions/listen.html
> <http://pubs.opengroup.org/onlinepubs/009695399/functions/listen.html>, but
> as described in http://bugs.python.org/issue8498
> <http://bugs.python.org/issue8498>, 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.
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.
Cory
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
