Yeah, I agree with you, creating a new ScriptRuntime is definitely the way to go, and we're definitely there yet :( - the good news is we think we'll be finishing that support up in February.
On cross-lang modules: The way you'd get a reference to these is via the normal import mechanism rather than the more programmatic sys.modules['Foo']. The way they get loaded is that import has some special magic which will call into the current ScriptRuntime and ask it to try and load the appropriately named module. Then the ScriptRuntime would ask the host to load the ScriptScope and depending on the host it'd search the web server, the file system, the database, etc... for the appropriately named file, and load it with the appropriate engine. So it's really all comes down to Python making one call into the DLR and the DLR returning a ScriptScope which pops back out of import. From then on out additional imports would hit the DLR's cache of ScriptScope for that particular name and return it. After thinking about it some more I'm leaning towards unifying globals & sys.modules - the only downside is potentially playing more games w/ dictionary types but we already do a lot of that anyway :(. PublishModule (I suspect you mean it's on ScriptEngine) is going away in the future as well - but that is going to sys.modules so for alpha 7 I'd suggest the hacky solution of just doing the del sys.modules[] and then once we have the global object worked out you'll just be able to remove the scopes from that - at least until we get multiple runtime support. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Curt Hagenlocher Sent: Friday, January 04, 2008 12:32 PM To: Discussion of IronPython Subject: Re: [IronPython] Deleting a module from the host I created and published the module myself using ScriptDomainManager.CurrentManager.CreateModule and ScriptDomainManager.CurrentManager.PublishModule. Hmm... I just noticed for the first time the naming inconsistency there between "Module" and "ScriptScope". To back up a step, I'm trying to TDD an integration layer between a C# app and some Python components, and I want to be able to basically "undo" the test actions so it won't influence the next test. If I understand the recent DLR hosting docs correctly, at some point I should be able to accomplish the same thing by creating new ScriptRuntimes instead -- but it looks like IronPython is not yet close to allowing this. When you consider that there might be published ScriptScopes in many different languages then, yeah, it really complicates the potential relationship between the "global object" (that's global per runtime, yes?) and sys.modules. I would certainly want to be able to use DLR modules (sorry, "ScriptScopes") from Python without worrying about their implementation language. How can I get a reference to them if not through sys.modules ? How do they get loaded in the first place? What's role does the Python loader and its extensibility mechanisms play when Python code causes a Javascript module to be loaded? Plenty of fun questions! On Jan 4, 2008 9:23 AM, Dino Viehland <[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>> wrote: 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]> [mailto: [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]<mailto:[email protected]> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________ Users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
