[IronPython] socket, _socket, and socket.py

[Zachary Gramana]

Thanks Curt.  That's encouraging news to hear.

I've noticed that some Python projects have a dependency on being able 
to standard library methods and types.  For example, Mercurial replaces 
buffer() with their own fakebuffer(), but ipy socket reads still return 
the original buffer.  I ended up patching around their monkey patch, 
which, understandably, they weren't too keen on importing back into 
their repo. An eventual move to _socket + socket.py wrapper could help 
improve compatibility with those projects.

These type of hidden dependencies on vm-specific behaviors seem to the 
biggest source of issues I've come across so far (in 2.7, anyway).  I'm 
continually amazed at how big of a step forward the team made from 2.6 
-> 2.7 with respect to compatibility.


On 5/17/2011 5:58 PM, Curt Hagenlocher wrote:
> Originally, we weren't allowed to redistribute the Python standard
> library with IronPython. So it made sense to implement the socket module
> directly. When IronPython started shipping the standard lib, it could
> have been changed, but never was. I think it makes sense to follow the
> CPython pattern.
>
> On Tue, May 17, 2011 at 2:33 PM, Zachary Gramana
> <zgramana at pottsconsultinggroup.com
> <mailto:zgramana at pottsconsultinggroup.com>> wrote:
>
>     Hi:
>
>     I've been working on adapting Mercurial to run on IronPython 2.7,
>     and ran into http://ironpython.codeplex.com/workitem/26852 which has
>     stopped me from getting `hg clone` working over SSL.
>
>     I noticed that for the ssl module, the IPY team mirrored the CPython
>     pattern of placing the platform-specific code in the _ssl compiled
>     module, and then wrapped the platform-independent around it in
>     ssl.py (almost entirely shared with CPython 2.7).
>
>     The socket module, however, does not.  I admit I have a limited
>     understanding of the code, but at first blush, it appears that
>     adopting the _socket.cs/socket.py isn't out-of-the-question. Is
>     there a story behind this, or am I missing something obvious to
>     everyone else?
>
>     The immediate benefit would be getting a free implementation of
>     _socketobject, _dummy, and dup(); it also improves DRY conformance,
>     and would help to limit behavioral differences with respect to other
>     implementations.
>
>     Thanks!
>
>     Regards,
>     Zack
>
>     P.S. Any advice on tackling issue #26852 is very warmly appreciated.
>     _______________________________________________
>     Users mailing list
>     Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>     http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com