[IronPython] Compiled dlls and builtin modules

[Dino Viehland]

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 :)

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Glenn Jones
Sent: Friday, December 12, 2008 8:27 AM
To: Discussion of IronPython
Subject: [IronPython] Compiled dlls and builtin modules

Hi all,

We are compiling the python standard library (so it can be ngend when it is shipped with Resolver One) and we've discovered that modules in the dll take precedence over builtins. We noticed this because re and socket are included in the standard Lib directory (installed with IPy2) and when we ran against the dll built from the Lib, importing them failed.

We have removed the following files from the standard library (and we may have to remove some others):
socket, copy_reg, re, sre_compile, sre_constants, sre_parse (the sre_* were referenced in re)

A better solution would be for builtin modules to take precedence over modules in referenced assemblies.

As an experiment, we created a datetime module that just printed that it was being imported. When we included it in a dll and referenced it, it replaced the builtin datetime.

Glenn & Orestis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081215/cbafe09d/attachment.html>