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 <di...@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-boun...@lists.ironpython.com [mailto: > users-boun...@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 < > zgram...@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@lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > _______________________________________________ > Users mailing list > Users@lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > >
_______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
