In Python speak it's importing. Python has very rich import semantics and has multiple ways of being hooked. Here's some info on that http://wikikk.com/doc/2.3/whatsnew/section-pep302.html. That'll leave all the normal file system access there (for things like the standard library) and still let you plug in to the import machinery.
>From the DLR side we just talk to the "file system" where the file system is >defined by the PlatformAdaptionLayer. IronPython uses the PAL to implement >its normal import machinery. So for storing files in the database you could >subclass PlatformAdaptionLayer and override the various file system APIs. >You'll need a ScriptHost that provides the PAL and you provide the type of the >ScriptHost via a ScriptRuntimeSetup class when creating the ScriptRuntime. >This is the mechanism Silverlight causes module imports to get redirected. From: [email protected] [mailto:[email protected]] On Behalf Of Marco Parenzan Sent: Monday, September 07, 2009 3:41 PM To: [email protected] Subject: [IronPython] Probing for Modules Dear all, I have not read Hosting document yet, but I advance with an answer. What about "module probing": I don't know how it is called in Python and DLR. Probing is the assembly discovery in .NET. Where should I look if I'd like to change the way the DLR discover modules? For example, if I'd like to store python modules in a DB and not in file system? Do I have an API and some events (like AssemblyResolve event?) Or do I have some code to change in DLR code base? Thanks in advance. Marco Parenzan
_______________________________________________ Users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
