[IronPython] socket, _socket, and socket.py
zgramana at pottsconsultinggroup.com
Wed May 18 00:19:53 CEST 2011
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:
> 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
> 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>
> Users mailing list
> Users at lists.ironpython.com
More information about the Ironpython-users