Irmen de Jong wrote:

Steve Holden wrote:

Having said which, if the module was loaded from a .pyc file then the bytecode is available from that - take everything but the first eight bytes and use marshal.loads() to turn it back into a code object:


Yup. As I explained in the other message, this is basically
what I'm doing at the moment (with a few twists; it reads the .py
file if no .pyc is available).
But I also want the bytecode of modules that don't have a .pyc file,
possibly because they have already been 'dynamically' loaded from
another bytecode string ;-)

Aah, right, I suspect in these cases (which *are* pretty far from the ordinary run of things) you'd sometimes be up the creek without a paddle.

Now, I could ofcourse store the bytecode string that I started
with *inside* the module itself, in a special attribute or so.
This just occurred to me and I think it's a possible solution.
But the bytecodes must be stored by Python itself somewhere
already... because Python is able to execute my module... right?

Not necessarily. I've just been playing with importing modules from a database. Here's the relevant extract from my load_module() function:


        code, package, path = row # ... from the database
        code = marshal.loads(code)
        module = DBmodule(modname) # subclass of moduleType
        sys.modules[modname] = module
        module.__name__ = modname
        module.__file__ = path # "db:%s" % modname
        module.__loader__ = dbimporter
        if package:
            module.__path__ = ["*db*"]
        exec code in module.__dict__
        #print modname, "loaded:", module, "pkg:", package
        return module

Note well that the module is essentially imported by executing its bytecode in the context of the module's directory. From that point on the module doesn't need access to its code - all its functions and classes have been created, and the functions and methods reachable from the module's __dict__ now have appropriate snippets of the byte code as their own code objects.

I want them! :-)

Well I'm afraid there's no guarantee that they haven't already been garbage collected, and stamping your foot isn't going to do any good :-)

Note that the ugly details *might* change, and that byte codes are version-dependent.


I know, but this fact was not yet mentioned in the Pyro manual.
Thanks for reminding me, I'll add it.

--Irmen

A pleasure. Thanks for Pyro! (and thanks for reminding me indirectly that I need to guard that execution of hte module's code against exceptions).


regards
 Steve
--
Meet the Python developers and your c.l.py favorites March 23-25
Come to PyCon DC 2005          http://www.python.org/pycon/2005/
Steve Holden                           http://www.holdenweb.com/
--
http://mail.python.org/mailman/listinfo/python-list

Reply via email to