-
Notifications
You must be signed in to change notification settings - Fork 0
Description
Preloaded extension methods are now working for /Python/ mods (commit 74bbf7f), but attempts to enable them for the console have continued to fail. Not only are they unable to be preloaded through the DLR interface, but clr.ImportExtensions doesn't appear to work within the console either; both silently fail. Though the actual point of failure could be anywhere between the actual import, and the name binding that happens after(/during?) code compilation.
So far I have investigated ModuleContexts being elusive, since that was the difficulty with enabling it for /Python/ mods.
A few things I have found that may be potentially interesting in an attempt to understand the lifecycle of CodeContext and ModuleContext, and how to manipulate them:
Builtin.GetExecEvalScope
PythonDynamicStackFrame
PythonOps.PublishModule / RemoveModule
PythonOps.CreateLocalContext
PythonOps.GetParentContextFromFunction
PythonOps.GetVariable
PythonOps.RawGetGlobal
PythonOps.RawGetLocal
ModuleTryGetMember //maybe proof of what Modules contain
\sCodeContext(/\*!\*/)?\s+\w+.*;
PythonScriptCode
RunnableScriptCode.GetContextForScope
PythonScopeExtensions
EnsureScopeExtension
Relationships I have come to understand:
- ScriptScope has a Scope, which has a PythonScopeExtension
- PythonScopeExtensions is likely the primary holder of ModuleContext. Its constructor creates a new ModuleContext
- ModuleContext has an ExtensionMethodSet. This is where the extension methods are.
Precise relationship between ModuleContext and CodeContext is still unclear. They may be codependent.
I wrote a tracer in the debug class to give tracebacks every time ModuleContext constructor is run. Further investigation of this might reveal why the ModuleContext is changing between setting the console's extensions and using the console, if that is indeed the problem at all.
The problem may well be something else entirely, such as to do with the usage of code.InteractiveInterpreter.