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
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 Sc
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
14632 looks pretty nasty and easy to fix. Good candidate for 1.1.1?
WeakObject.Equals throws null pointer exception
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=14632
WeakObject is an internal class of IronPython, a component used in WeakHash.
I would especially like it fixed
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
Yep, I think this can be fixed. I've got a tentative fix and it looks like it
works and doesn't break anything. Thanks for bringing attention to this.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kamil Dworakowski
Sent: Friday, January 04, 2008 12:36
On Jan 4, 2008 3:26 PM, Dino Viehland <[EMAIL PROTECTED]> wrote:
>
> 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 e
Yep, the host resolves the source code & the engine type (this is in
ScriptHost.ResolveSourceFileUnit which returns a ScriptSource (SourceUnit
today) which is already bound to an engine). We haven't yet closely reviewed
the ScriptHost API but I suspect it's pretty close to what it'll end up bei
