There is actually more of a story to this though - Cpython's relies 
upon reference counting for handling dup.  See this comment from

# 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  So someone would need to patch both IronPython and so 
this would work.  For the record it looks like Jython also has a custom

[] On Behalf Of Curt Hagenlocher
Sent: Tuesday, May 17, 2011 2:59 PM
To: Discussion of IronPython
Subject: Re: [IronPython] socket, _socket, and

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 

I've been working on adapting Mercurial to run on IronPython 2.7, and ran into 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 (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/ 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.



P.S. Any advice on tackling issue #26852 is very warmly appreciated.
Users mailing list<>

Users mailing list

Reply via email to