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
<zgram...@pottsconsultinggroup.com
<mailto: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 <mailto: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
