Socket module bug on OpenVMS

[Jean-Paul Calderone]

On Sun, 22 Oct 2006 19:58:44 +0200, Irmen de Jong <irmen.nospam at xs4all.nl> wrote:
>Jean-Paul Calderone wrote:
>> I think everyone can agree that Python shouldn't crash.
>
>Well, it doesn't really crash in a bad way, in my example:
>it doesn't work because it simply raises a socket exception all the time.

Okay.  I assumed you meant the interpreter died with a SIGSEGV or something
similar.  If the call simply raises an exception, then I'm not sure I see
a real problem here.

>
>> Whether Python should propagate other kinds of errors from the underlying
>> platform is a harder question though.  At the lowest level interface, it
>> seems to me that it _should_ propagate them.  If there is a general way to
>> handle them, then a higher layer can be built on top of that lowest level
>> which does so.
>
>We already have a low-level "_socket" module (builtin) and a higher level
>"socket" module (implemented in python in the std lib)...
>I could imagine that the "socket" module would offer methods that can deal
>with platform bugs such as the two I mentioned in my original posting.
>
>I have never used _socket directly by the way (and don't think anyone
>else ever did?)

The _ prefix indicates the module is private: you aren't *supposed* to use
_socket.  This may help internal factoring, but it's not useful for anyone
writing code that's not part of the standard library.  For the separation
I'm talking about to be useful, all layers need to be made available to
developers of third-party libraries.

What'd be really nice is a direct wrapper around recv(2), send(2), etc,
with a simple socket-object layer on top of that, with timeouts or error
handling layered on top of that.

Jean-Paul