Message7217

Author amak
Recipients amak, varialus
Date 2012-06-14.08:21:05
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1339662066.2.0.915924412352.issue1918@psf.upfronthosting.co.za>
In-reply-to
Content
> 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".
History
Date User Action Args
2012-06-14 08:21:06amaksetmessageid: <1339662066.2.0.915924412352.issue1918@psf.upfronthosting.co.za>
2012-06-14 08:21:06amaksetrecipients: + amak, varialus
2012-06-14 08:21:06amaklinkissue1918 messages
2012-06-14 08:21:05amakcreate