Yeah, I would like to see us more closely match the C modules as well. Socket is particularly challenging though because socket.py depends on the ref counting semantics of CPython's garbage collector.
From: [email protected] [mailto:[email protected]] On Behalf Of Curt Hagenlocher Sent: Monday, December 15, 2008 3:50 PM To: Discussion of IronPython Subject: Re: [IronPython] Compiled dlls and builtin modules Sounds waaay too easy :P. In the long run, I'd prefer that we implement only the "C" part of these modules and share the Python part with CPython. But this is not only a potentially breaking change, it also would require modification to the standard library for at least the "socket" module. On Mon, Dec 15, 2008 at 3:04 PM, Michael Foord <[email protected]<mailto:[email protected]>> wrote: Dino Viehland wrote: I think this behavior is currently by design because we're using sys.meta_path which does take precedence over the built-in modules. We could switch to using sys.path_hooks in 2.1 or 3.0 if the consensus is this behavior in undesirable (which would also give control over when pre-compiled modules take precedence over other places on sys.path). Personally I'm +0 to make the change but this would probably break the other recently reported behavior w/ combinations on disk as .py files & precompiled files J Another suggestion is that you stop including these unneeded modules in the version of the standard library shipped with the IronPython 2 installer.
_______________________________________________ Users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
