开发者

dynamic module creation

开发者 https://www.devze.com 2023-01-02 00:42 出处:网络
I\'d like to dynamically create a module from a dictionary, and I\'m wondering if adding an element to sys.modules is really the best way to do this.EG

I'd like to dynamically create a module from a dictionary, and I'm wondering if adding an element to sys.modules is really the best way to do this. EG

context = { a: 1, b: 2 }
import types
test_context_module = types.ModuleType('TestContext', 'Module created to provide a context for tests')
test_context_module.__dict__.update(context)
import sys
sys.modules['TestContext'] = test_context_module

My immediate goal in this regard is to be able to provide a context for timing test execution:

import timeit
timeit.Timer('a + b', 'from TestContext import *')

It seems that there are other ways to do this, since the Timer constructor takes objects as well as strings. I'm still interested in learning how to do this though, since a) it has other potential applications; and b) I'm not sure exactly how to use objects with the Timer constructor; doing so may prove to be less appropriate than this approach in some circumstances.

EDITS/REVELATIONS/PHOOEYS/EUREKA:

  1. I've realized that the example code relating to running timing tests won't actually work, because import * only works at the module level, and the context in which that statement is executed is that of a function in the testit module. In other words, the globals dictionary used when executing that code is that of __main__, since that's where I was when I wrote the code in the interactive shell. So that rationale for figuring this out is a bit botched, but it's still a valid question.

  2. I've discovered that the code run in the first set of examples has the undesirable effect that the namespace in which the newly created module's code executes is that of the module in which it was declared, not its own module. This is like way weird, and could lead to all sorts of unexpected rattlesnakeic sketchiness. So I'm pretty sure that this is not how this sort of thing is meant to be done, if it is in fact something that the Guido doth shine upon.

  3. The similar-but-subtly-different case of dynamically loading a module from a file that is not in python's include path is quite easily accomplished using imp.load_source('NewModuleName', 'path/to/module/module_to_load.py'). This does load the module into sys.modules. However this doesn't really answer my question, because really, what if you're running python on an embedded platform with no filesystem?

I'm battling a considerable case of in开发者_StackOverflow中文版formation overload at the moment, so I could be mistaken, but there doesn't seem to be anything in the imp module that's capable of this.

But the question, essentially, at this point is how to set the global (ie module) context for an object. Maybe I should ask that more specifically? And at a larger scope, how to get Python to do this while shoehorning objects into a given module?


Hmm, well one thing I can tell you is that the timeit function actually executes its code using the module's global variables. So in your example, you could write

import timeit
timeit.a = 1
timeit.b = 2
timeit.Timer('a + b').timeit()

and it would work. But that doesn't address your more general problem of defining a module dynamically.

Regarding the module definition problem, it's definitely possible and I think you've stumbled on to pretty much the best way to do it. For reference, the gist of what goes on when Python imports a module is basically the following:

module = imp.new_module(name)
execfile(file, module.__dict__)

That's kind of the same thing you do, except that you load the contents of the module from an existing dictionary instead of a file. (I don't know of any difference between types.ModuleType and imp.new_module other than the docstring, so you can probably use them interchangeably) What you're doing is somewhat akin to writing your own importer, and when you do that, you can certainly expect to mess with sys.modules.

As an aside, even if your import * thing was legal within a function, you might still have problems because oddly enough, the statement you pass to the Timer doesn't seem to recognize its own local variables. I invoked a bit of Python voodoo by the name of extract_context() (it's a function I wrote) to set a and b at the local scope and ran

print timeit.Timer('print locals(); a + b', 'sys.modules["__main__"].extract_context()').timeit()

Sure enough, the printout of locals() included a and b:

{'a': 1, 'b': 2, '_timer': <built-in function time>, '_it': repeat(None, 999999), '_t0': 1277378305.3572791, '_i': None}

but it still complained NameError: global name 'a' is not defined. Weird.

0

精彩评论

暂无评论...
验证码 换一张
取 消