Thanks again Dino: it's all working and checked in, and it was all much
easier than I expected. No problems with SourceUnits, but I don't try to
do anything remotely complex with them, so others' mileage may vary.
Dino Viehland wrote:
Oh, and instead of ScriptSource you can use SourceUnit.
Hi all
At the moment, when a user types 'import ironclad', I create a new
ScriptEngine and set that up to allow .pyd imports; I then abuse
path_hooks to use the new engine to do the imports, and copy them into
the original engine's sys.modules. Clearly, this is evil and wrong on
any number
It's not really possible to get back to the ScriptEngine - but you also
probably don't need to. You probably want to get back to the
LanguageContext(PythonContext)/ScriptDomainManager and work with those
directly. ScriptEngine/ScriptRuntime are wrappers around those which expose
the friendly
Thanks Dino -- I'll see what I can do with that :)
Dino Viehland wrote:
It's not really possible to get back to the ScriptEngine - but you also
probably don't need to. You probably want to get back to the
LanguageContext(PythonContext)/ScriptDomainManager and work with those
directly.
It seems I don't actually use the engine for very much, so this sounds
pretty plausible -- context.SystemState can replace Python.GetSysModule,
and HostingHelpers.GetLanguageContext goes away entirely :).
However, I can't see any obvious way to create a ScriptScope
(engine.CreateScope) or a
Just create Scope objects instead of ScriptScope's. Scope's are what we
actually expose as modules directly to Python programs. Generally only hosting
APIs see the ScriptScope's.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of William Reade
Sent:
Oh, and instead of ScriptSource you can use SourceUnit. You might find there's
too much stuff marked internal w/ SourceUnit so any issues you run into here
would be interesting to hear.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of William Reade
