Being new to the community, I hope that I am not being too big of a nuisance and causing you too many problems. As fate would have it, I just happen to be in the final stages of developing new code using Socket with Jython at this particular moment in time and I am one of those that used threads because Select was not available. Once again, I am impressed with the quality of your Socket and Select upgrades. I also know about (and am quite glad about) the desire to get Jython upgraded. I am experienced enough to know the magnitude of making a change like this with the goal of complete compatibility with CPython.
For the 2.2 release, I am fine with option B. I can open problems and submit simple examples illustrating what I think is a problem like I just did for the Permission Denied socket question. However, I don't know how to make an entry in the mapping table, and then submit that as a patch. I am willing to do this, but I need some direction in how to do it. Could you or someone else help me to get started? I also could spend some limited time helping you to do this mapping when other problems are opened. As with everyone, my time is limited, but please let me know if you think I could help. I also am offering to help look for exceptions that do not match and make the appropriate updates.
My main concern has not been to just complain, but to inform you of issues that I think that you would want to know about. I have not seen anything that I would consider a show stopper for 2.2. I do know computer users, though, and I do know how some people will react when code that worked in 2.1 that is syntactically correct will not work in 2.2. I agree with the judgment calls you guys are making. I happened to be at a point where I could fairly easily change my code. My goal is not to be a hindrance, but to just make sure that you and Charlie and others are making informed decisions.
So, please, point me in the direction of getting started updating the mapping table and how to submit that as a patch.
From: Alan Kennedy <firstname.lastname@example.org>
To: JythonDevelopers <email@example.com>
Sent: Sun, 15 Jul 2007 7:22 am
Subject: [Jython-dev] Socket exception handling.
There seems to be some confusion about socket exception handling in the
new socket module. This probably arises from the mechanism I have chosen
for handling exceptions.
Raising exceptions has two goals.
1. To enable code to determine the cause of an exception, so that a
program can adjust its behaviour accordingly. For example, if an attempt
is made to connect to a non-existent address, the script should be able
to determine that, and either find a new address to connect to, or
abandon the attempt.
2. To give a meaningful error message to the coder, so that when they
are developing their code and an exception happens, they can determine
the meaning of the exception, and adjust their code accordingly.
When working on the socket module, I tried to make its behaviour as
close as possible to the behaviour of the cpython socket module. This
was to support, as much as possible, being able to run cpython socket
code, unmodified, under jython. This would be an enormous benefit, since
it would mean that people using cpython would be able to run their code
out-of-the-box on jython.
However, in order for the exception handling to be identical, a mapping
from every possible java exception to the relevant cpython exception is
But the socket module, as is, does not have a complete mapping: it
currently only maps the most common exceptions. To provide a complete
mapping would require examing every possible java socket exception in
detail, seeing what circumstances it is raised under, seeing what
cpython does in the same situation, and making an entry in the mapping
It was my hope that this mapping table would expand incrementally over
time, with the users helping out (hey, this is open source!), either by
1. Making an entry in the mapping table themselves, and making it
available as a patch which we could apply to the source.
2. By reporting bugs where a socket exception is not mapped, and
providing code snippets which illustrate the problem.
But it appears that strategy is not working out; people are simply
complaining about getting an exception that isn't exactly the same as
the cpython exception, without taking one of the two strategies above.
So we're at a decision point; We have to decide whether to
A: Complete the mapping for all possible java exceptions, before jython
2.2 final is released.
B: Leave the status quo as is, and complete the mapping table
incrementally over time, with completion coming sometime after the
release of jython 2.2.
C: Abandon the idea of exception mapping, and go back to the old
mechanism of simply raising the java exception, and let the user deal
with that. Code would no longer be directly portable between cpython and
I don't have a lot of time for option A right now; I have a lot of
things on my plate. I could probably get to it sometime later this week.
I had always hoped that someone else would volunteer to help out with
this, e.g. some of the people who were very keen to get the new module
into jython 2.2
Option B is what we get if we do nothing, i.e. it is the status-quo.
Option C is the simplest and quickest solution to the problem, but also
the least attractive in terms of jython<->cpython compatibility.
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
Jython-dev mailing list