Unfortunately the answer is it depends, and it's probably not supported in Alpha 7 :(
The depends part is how the module got there and it all revolves around the design we've come up with for the hosting of multiple languages. We have a global object per ScriptRuntime which is (currently) a ScriptScope. That scope holds onto a bunch of name/value bindings (where a value could be another nested ScriptScope) and this is the closest concept (in the DLR) we have to a module. The idea then is that each language exposes the global object via its own mechanism picking something that makes the most sense for that language. IronPython is going to expose the global object via import much like it exposes other modules and .NET namespaces. But that doesn't mean sys.modules goes away, or that sys.modules becomes the global object. Instead what we're currently planning on doing is having import fallback to the global object just as it falls back to the namespaces today. (As I type this I realize it does complicate this scenario - so I'll ask if this sound crazy or like a bad idea? Should we instead try to merge them and have sys.modules == global object? That has its own potential quirks but they could be dealt with.) So that gives two different locations where modules can be published: Either in the global object or in sys.modules. Therefore how you added the module effects how the module gets removed. If the user did "import foo" and we pulled up a .py file it'll end up being in sys.modules. If we pulled up a .js file from the DLR then it'll be in the global object. Further complicating things is the fact that the global object isn't really implemented yet. There's some remnants of the old cross-language module support we had early on but that's not really the global object. So for now in Alpha 7 I think the answer is that you execute the code. There's also one more future possibility: And that is that to expose Python specific functionality we may need to have a PythonEngine class or something that lets you do things that aren't part of the least common denominator. There accessing sys.modules would be a likely piece of functionality to have. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Curt Hagenlocher Sent: Friday, January 04, 2008 6:03 AM To: Discussion of IronPython Subject: [IronPython] Deleting a module from the host In a previous alpha of IPY 2.0, I deleted modules by saying PythonEngine.CurrentEngine.SystemState.modules.Remove(moduleName) (which is almost a direct analog of "del sys.modules[moduleName]"). What's the best approach in Alpha 7? And will this change as IronPython continues to migrate to the DLR? I suppose I could literally execute Python code to do what I want, but it seems so inelegant... -- Curt Hagenlocher [EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>
_______________________________________________ Users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
