[IronPython] socket, _socket, and socket.py

[Curt Hagenlocher]

Ah, right, I'd forgotten that -- we would have had to have distributed a
modified socket.py, and that was infeasible even after we were delivering
the standard library. This feels like a place where IronPython could
collaborate on a joint change with Jython and have the result distributed
inside the standard library using a test for sys.platform.

On Tue, May 17, 2011 at 3:06 PM, Dino Viehland <dinov at microsoft.com> wrote:

>  There is actually more of a story to this though – Cpython’s socket.py
> relies upon reference counting for handling dup.  See this comment from
> socket.py:
>
>
>
> # Wrapper around platform socket objects. This implements
>
> # a platform-independent dup() functionality. The
>
> # implementation currently relies on reference counting
>
> # to close the underlying socket object.
>
> class _socketobject(object):
>
>
>
> Because IronPython doesn’t have a reference counting GC we cannot simply
> use socket.py.  So someone would need to patch both IronPython and socket.py
> so this would work.  For the record it looks like Jython also has a custom
> socket.py.
>
>
>
> *From:* users-bounces at lists.ironpython.com [mailto:
> users-bounces at lists.ironpython.com] *On Behalf Of *Curt Hagenlocher
> *Sent:* Tuesday, May 17, 2011 2:59 PM
> *To:* Discussion of IronPython
> *Subject:* Re: [IronPython] socket, _socket, and socket.py
>
>
>
> 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> 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
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20110517/a2f14c8b/attachment.html>