467,075 Members | 971 Online
Bytes | Developer Community
Ask Question

Home New Posts Topics Members FAQ

Post your question to a community of 467,075 developers. It's quick & easy.

What is the cleanest way to for a module to access objects from the script that imports it?

Hi,

I am new to python and am currently writing my first application. One
of the problems I quickly ran into, however, is that python's imports
are very different from php/C++ includes in the sense that they
completely wrap the imported script in a module object. One of the
problems with this was that a plugin system that I am making requires
use of objects, classes and the such from the original script. Thus, on
one hand, I am hesitant to use execfile(), since I *do* want to wrap
the plugin up, but on the other hand, I want the plugin to be able to
use functions from the original script. Any ideas?

Sincerely,
Noam Samuel.

Oct 27 '06 #1
  • viewed: 993
Share:
9 Replies
At Friday 27/10/2006 18:53, no*****@gmail.com wrote:
>I am new to python and am currently writing my first application. One
of the problems I quickly ran into, however, is that python's imports
are very different from php/C++ includes in the sense that they
completely wrap the imported script in a module object. One of the
problems with this was that a plugin system that I am making requires
use of objects, classes and the such from the original script. Thus, on
one hand, I am hesitant to use execfile(), since I *do* want to wrap
the plugin up, but on the other hand, I want the plugin to be able to
use functions from the original script. Any ideas?
Put the bulk of your "original script" into modules so they are
easily importable from inside the plugins.
In your application, you can scan the available plugins (using
os.listdir by example) and import them.
(Of course this is risky so you must trust the plugin developers...)
--
Gabriel Genellina
Softlab SRL

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ˇgratis!
ˇAbrí tu cuenta ya! - http://correo.yahoo.com.ar
Oct 27 '06 #2
Wouldn't importing and re-importing the same modules cause considerable
resource bulk? Or does python cache that stuff?

On Oct 27, 6:28 pm, Gabriel Genellina <gagsl...@yahoo.com.arwrote:
At Friday 27/10/2006 18:53, noam...@gmail.com wrote:
I am new to python and am currently writing my first application. One
of the problems I quickly ran into, however, is that python's imports
are very different from php/C++ includes in the sense that they
completely wrap the imported script in a module object. One of the
problems with this was that a plugin system that I am making requires
use of objects, classes and the such from the original script. Thus, on
one hand, I am hesitant to use execfile(), since I *do* want to wrap
the plugin up, but on the other hand, I want the plugin to be able to
use functions from the original script. Any ideas?Put the bulk of your "original script" into modules so they are
easily importable from inside the plugins.
In your application, you can scan the available plugins (using
os.listdir by example) and import them.
(Of course this is risky so you must trust the plugin developers...)

--
Gabriel Genellina
Softlab SRL

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ˇgratis!
ˇAbrí tu cuenta ya! -http://correo.yahoo.com.ar
Oct 27 '06 #3
no*****@gmail.com wrote:
Wouldn't importing and re-importing the same modules cause considerable
resource bulk? Or does python cache that stuff?
If a module is already imported, then the import statement just uses the
cached module. However, you can force a full reload of the module using
the following syntax:

reload(mymodule)

-Farshid
Oct 27 '06 #4
At Friday 27/10/2006 19:48, no*****@gmail.com wrote:
>Wouldn't importing and re-importing the same modules cause considerable
resource bulk? Or does python cache that stuff?
No. Once a module is imported by the first time, the module object is
placed in sys.modules; if a subsequent import finds the module there,
it's not reloaded from disk.
See <http://docs.python.org/ref/import.html>
--
Gabriel Genellina
Softlab SRL

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ˇgratis!
ˇAbrí tu cuenta ya! - http://correo.yahoo.com.ar
Oct 27 '06 #5
no*****@gmail.com schrieb:
Hi,

I am new to python and am currently writing my first application. One
of the problems I quickly ran into, however, is that python's imports
are very different from php/C++ includes in the sense that they
completely wrap the imported script in a module object. One of the
problems with this was that a plugin system that I am making requires
use of objects, classes and the such from the original script. Thus, on
one hand, I am hesitant to use execfile(), since I *do* want to wrap
the plugin up, but on the other hand, I want the plugin to be able to
use functions from the original script. Any ideas?
If you really have a C++ background, you should be aware that this
language requires each and every bit of declarations to be known
beforehand. Which means you need stuff to be factorized into header
files, and include them wherever you want to use things.

Python is waaaay more relaxed in this regard. As long as you only use
objects, it actually doesn't give a damn about "knowing" them. if you
need to instantiate them, there isn't anything wrong about importing a
main module from a plugin module - you can do that. However, things can
get messed up if you really do a circular import, meaning that you don't
have a plugin system with lazy loading, but "real" cycles.

Diez
Oct 28 '06 #6
no*****@gmail.com wrote:
Hi,

I am new to python and am currently writing my first application. One
of the problems I quickly ran into, however, is that python's imports
are very different from php/C++ includes in the sense that they
completely wrap the imported script in a module object. One of the
problems with this was that a plugin system that I am making requires
use of objects, classes and the such from the original script. Thus, on
one hand, I am hesitant to use execfile(), since I *do* want to wrap
the plugin up, but on the other hand, I want the plugin to be able to
use functions from the original script. Any ideas?
you can import __main__ in your module: import __main__; __main__.app_xfunc(y)

But for most cases I'd say your "problem" is an indication of weak design (thanks to Pythons clear module tech).

Maybe:

* if the funcs are tools, put them in an extra module

* if its about app-global parameters(tools), make a module "myglob" or so

* if the funcs have app-context, hand over/set them as "callback" functions or iterators like ..

def app_xfunc(par):pass
mody.set_xhandler(app_xfunc)
mody.yfunc(a,b,..., cbProgress=app_xfunc)
def app_xstepper():
yield next
mody.yfunc2(a,b,..., step=app_xstepper)
....
* if you have 2 moduls on equal dependency level and each needs the other (sometimes) - thus you don't want to have one big module, then cross import them ..

#modx
import mody
def fx():
mody.doy()
#mody
import modx
def fy():
modx.dox()
Python allows everything most easy for that kind of problems of all langs I know of. Mainly the fact that a module is a real object in Python provides tremendous flexibility and self-similarity of techniques. Ruby for example is weired - even really bad - in this.

-robert
Oct 28 '06 #7

robert ha escrito:
no*****@gmail.com wrote:
Hi,

I am new to python and am currently writing my first application. One
of the problems I quickly ran into, however, is that python's imports
are very different from php/C++ includes in the sense that they
completely wrap the imported script in a module object. One of the
problems with this was that a plugin system that I am making requires
use of objects, classes and the such from the original script. Thus, on
one hand, I am hesitant to use execfile(), since I *do* want to wrap
the plugin up, but on the other hand, I want the plugin to be able to
use functions from the original script. Any ideas?

you can import __main__ in your module: import __main__; __main__.app_xfunc(y)

But for most cases I'd say your "problem" is an indication of weak design (thanks to Pythons clear module tech).

Maybe:

* if the funcs are tools, put them in an extra module

* if its about app-global parameters(tools), make a module "myglob" or so

* if the funcs have app-context, hand over/set them as "callback" functions or iterators like ..

def app_xfunc(par):pass
mody.set_xhandler(app_xfunc)
mody.yfunc(a,b,..., cbProgress=app_xfunc)
def app_xstepper():
yield next
mody.yfunc2(a,b,..., step=app_xstepper)
...
* if you have 2 moduls on equal dependency level and each needs the other (sometimes) - thus you don't want to have one big module, then cross import them ..

#modx
import mody
def fx():
mody.doy()
#mody
import modx
def fy():
modx.dox()
Python allows everything most easy for that kind of problems of all langs I know of. Mainly the fact that a module is a real object in Python provides tremendous flexibility and self-similarity of techniques. Ruby for example is weired - even really bad - in this.

-robert
Oct 28 '06 #8
On Fri, 2006-10-27 at 14:53 -0700, no*****@gmail.com wrote:
Hi,

I am new to python and am currently writing my first application. One
of the problems I quickly ran into, however, is that python's imports
are very different from php/C++ includes in the sense that they
completely wrap the imported script in a module object. One of the
problems with this was that a plugin system that I am making requires
use of objects, classes and the such from the original script. Thus, on
one hand, I am hesitant to use execfile(), since I *do* want to wrap
the plugin up, but on the other hand, I want the plugin to be able to
use functions from the original script. Any ideas?
I have a system that uses modules as plugins also. These are loaded
dynamically when the user specifies them from a gui. I put all these
modules in an array using the __import__ function. I found, though,
that I needed to specify whether or not each module had actually loaded,
or if there had been an exception (module not found or whatever). So I
wrote a wrapper object that would try to load the module and store it as
a local attribute. I made my wrapper object implement functions like
__getattr__ and pass any unknown calls into the module object itself,
making the wrapper object act as if it was the module, but having extra
capabilities, such as being able to tell me if the module had actually
loaded or not.

Michael

>
Sincerely,
Noam Samuel.
Oct 31 '06 #9

no*****@gmail.com wrote:
Hi,

I am new to python and am currently writing my first application. One
of the problems I quickly ran into, however, is that python's imports
are very different from php/C++ includes in the sense that they
completely wrap the imported script in a module object. One of the
problems with this was that a plugin system that I am making requires
use of objects, classes and the such from the original script. Thus, on
one hand, I am hesitant to use execfile(), since I *do* want to wrap
the plugin up, but on the other hand, I want the plugin to be able to
use functions from the original script. Any ideas?
This is a situation I've been in before when writing plugins - you need
some way of 'connecting' the plugin to the main application.

I usually provide a baseclass which the user should subclass to
implement the plugin.

The override something like an 'onActivate' method, which when called,
is passed in (by the application) all the information they need.

They can also optionally override 'onLoad' and 'onUnload' or whatever
other methods you want to provide.

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml
Sincerely,
Noam Samuel.
Oct 31 '06 #10

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

54 posts views Thread by Brandon J. Van Every | last post: by
28 posts views Thread by David MacQuigg | last post: by
4 posts views Thread by Brad Tilley | last post: by
6 posts views Thread by kimes | last post: by
31 posts views Thread by N.Davis | last post: by
121 posts views Thread by typingcat@gmail.com | last post: by
reply views Thread by Jorgen Bodde | last post: by
6 posts views Thread by Samuel | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.