Issue1918

Python code written for CPython should run without modification in Jython. Some unacceptable implementation differences (of unspecified priority) can be demonstrated by the changes required for Selenium to run correctly in Jython. These changes are documented at the following URL.

https://code.google.com/p/selenium/issues/detail?id=3988

The implementation difference demonstrated by the common_utils.py patch file at the above URL is documented within the section "Deferred socket creation on jython" at the following URL.

http://wiki.python.org/jython/NewSocketModule#Deferred_socket_creation_on_jython

Documentation about the differences between Jython and CPython is valuable and appreciated, but it should not be considered an acceptable permanent solution.

> Documentation about the differences between Jython and CPython ... should not be considered an acceptable permanent solution.

Perhaps the wiki documentation is not explicitly clear enough: no other solution is possible: this is a issue that has no "permanent" solution.

The deferred identity of sockets on jython is necessary because there is no other way of determining whether a socket is a client or server socket.

If it were possible to modify the cpython socket API so that the user is forced to declare the client/server nature of the socket in advance, then this would solve the problem. But I don't believe that the cpython community would accept such a change.

It is worth noting that other JVM languages have chosen this option. JRuby, for example, has separate classes for client and server sockets

https://github.com/jruby/jruby/wiki/ServerSocket

The only other option is to infer from code behaviour, i.e. whether the code calls "connect" or "listen", which is the option used in jython. This is the option that your code patch has taken: "declaring" that the socket is a server socket by adding a "listen" call.

There are few situations where this makes a difference, but your use case is one of them. The expectation that you can bind a socket to an ephemeral port, without either connect'ing or listen'ing on the socket, and then retrieve the actual port number assigned, is false, and must remain false. Again, if the socket API could be extended to contain a method for obtaining an ephemeral port, then your problem would not exist. But making an addition to the API is unlikely to be acceptable to cpython community.

If there is some wording or other way of saying that would make this more explicitly clear, then I'm happy to update the documentation.

But there is no other solution to the problem than the solution currently implemented.

So I'm afraid I have to close this bug report as "rejected".