[IronPython] Compiled dlls and builtin modules

Dino Viehland dinov at microsoft.com
Tue Dec 16 01:36:44 CET 2008


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: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] 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 <fuzzyman at voidspace.org.uk<mailto:fuzzyman at voidspace.org.uk>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081215/7e974bfa/attachment.html>


More information about the Ironpython-users mailing list