467,169 Members | 968 Online
Bytes | Developer Community
Ask Question

Home New Posts Topics Members FAQ

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

Re: Function to import module to namespace

Terry Reedy wrote:
>
<snip>
>
Do you mean something like this?
<snip>
>>math.__dict__.update(string.__dict__)
>>dir(math)
['Formatter', 'Template', '_TemplateMetaclass', '__builtins__',
<snip>

I think this is working.... First off, 2 module files:

funcs.py
def func1():
print "I'm func1 in funcs.py"

more.py
def func2():
print "I'm func2 in 'more.py'"

and my wonderful main program:

xx.py
import funcs
def addnewfuncs(p):
x = __import__(p)
funcs.__dict__.update(x.__dict__)
funcs.func1()
addnewfuncs('more')
funcs.func2()

The first problem I had was getting import to accept a variable. It
doesn't seem to, so I used __import__(). Then, I had to remember to
assign this to a variable ... and then it appears to work just fine.

Did I miss anything in this???

Thanks for the pointer!

Bob.
Jun 29 '08 #1
  • viewed: 971
Share:
4 Replies
On Jun 30, 9:52 am, bvdp <b...@mellowood.cawrote:
Terry Reedy wrote:
>

<snip>
>
Do you mean something like this?

<snip>
>>math.__dict__.update(string.__dict__)
>>dir(math)
['Formatter', 'Template', '_TemplateMetaclass', '__builtins__',

<snip>

I think this is working.... First off, 2 module files:

funcs.py
def func1():
print "I'm func1 in funcs.py"

more.py
def func2():
print "I'm func2 in 'more.py'"

and my wonderful main program:

xx.py
import funcs
def addnewfuncs(p):
x = __import__(p)
funcs.__dict__.update(x.__dict__)
funcs.func1()
addnewfuncs('more')
funcs.func2()

The first problem I had was getting import to accept a variable. It
doesn't seem to, so I used __import__(). Then, I had to remember to
assign this to a variable ... and then it appears to work just fine.

Did I miss anything in this???
You are updating with *everything* in the 'more' module, not just the
functions. This includes such things as __name__, __doc__, __file__.
Could have interesting side-effects.

One quick silly question: why do you want to do this anyway?

Sorry, *two* quick silly questions: are the add-on modules under your
control, or do you want to be able to do this with arbitrary modules?
[If under your control, you could insist that such modules had an
__all__ attribute with appropriate contents]

A third: why do you want to import into an existing namespace? Now
that you know about __import__, why just not call the functions where
they are?

Cheers,
John
Jun 30 '08 #2
John Machin wrote:

<snip>

Good questions. Short answer ... probably 'cause I've not thought the
problem though completely :)
You are updating with *everything* in the 'more' module, not just the
functions. This includes such things as __name__, __doc__, __file__.
Could have interesting side-effects.

One quick silly question: why do you want to do this anyway?
I'm writing a "simple" macro expander. I've got some mainline code which
reads an input file, parses out macros, and expands them. So, in my
input file I might have something like:

a fjas j kj sdklj sdkl jfsdkl [ link somewhere sometext ]

So, I need a function link() to evaluate and return "http://...."

Instead of putting funcs like link() in my mainline I've stuck them in a
module of their own. In the mainline I

import funcs

and then when I need to expand I have the following code:

if not cmd in vars(funcs):
error("Unknown function/variable '%s'" % cmd)

if type(vars(funcs)[cmd]) == type(parse):
txt = eval("""funcs.%s("%s")""" % (cmd, arg))

else: # not a func, just expand the variable
if arg:
error("Argument to variable '%s' not permitted." % cmd)
txt = str(eval("funcs.%s" % cmd ))

Of course, the question comes up ... what if a user (probably me) wants
to add more functions? Easy enough to just edit funcs.py I suppose, but
I thought it'd be nice to use more modules.

So, I suppose that rather than adding the 2ndary module stuff to the
default 'funcs.py' I could just as well have a look and check for the
needed function in all the modules I've imported.

Sorry, *two* quick silly questions: are the add-on modules under your
control, or do you want to be able to do this with arbitrary modules?
[If under your control, you could insist that such modules had an
__all__ attribute with appropriate contents]
Why would I want to do that ... and how?
A third: why do you want to import into an existing namespace? Now
that you know about __import__, why just not call the functions where
they are?
Yeah, that would probably be cleaner (safer).

Thanks.
Jun 30 '08 #3
On Jun 30, 11:45 am, bvdp <b...@mellowood.cawrote:
John Machin wrote:

<snip>

Good questions. Short answer ... probably 'cause I've not thought the
problem though completely :)
You are updating with *everything* in the 'more' module, not just the
functions. This includes such things as __name__, __doc__, __file__.
Could have interesting side-effects.
>
One quick silly question: why do you want to do this anyway?
>

I'm writing a "simple" macro expander. I've got some mainline code which
reads an input file, parses out macros, and expands them. So, in my
input file I might have something like:

a fjas j kj sdklj sdkl jfsdkl [ link somewhere sometext ]

So, I need a function link() to evaluate and return "http://...."

Instead of putting funcs like link() in my mainline I've stuck them in a
module of their own.
Why? Do they have any use at all other than to be called by your
mainline?
In the mainline I

import funcs

and then when I need to expand I have the following code:
Build a dictionary *ONCE*, not each time you want to look in it. E.g.

funcs_vars = vars(funcs)

.... much later:

if not cmd in funcs_vars:

if not cmd in vars(funcs):
error("Unknown function/variable '%s'" % cmd)

if type(vars(funcs)[cmd]) == type(parse):
txt = eval("""funcs.%s("%s")""" % (cmd, arg))
Any particular reason why you are going to the trouble of laboriously
building a statement, compiling it, and running it, when you could
simply do:
txt = funcs_vars[cmd](arg)
?
>
else: # not a func, just expand the variable
if arg:
error("Argument to variable '%s' not permitted." % cmd)
txt = str(eval("funcs.%s" % cmd ))
txt = str(funcs_vars[cmd])
>
Of course, the question comes up ... what if a user (probably me) wants
to add more functions? Easy enough to just edit funcs.py I suppose, but
I thought it'd be nice to use more modules.
You may already have one more module than you need. If the only thing
different about the extra functions is that they are an afterthought,
then put them in the same module as the others.
>
So, I suppose that rather than adding the 2ndary module stuff to the
default 'funcs.py' I could just as well have a look and check for the
needed function in all the modules I've imported.
Sounds quite unnecessary, inefficient and pointless to me.
>
Sorry, *two* quick silly questions: are the add-on modules under your
control, or do you want to be able to do this with arbitrary modules?
[If under your control, you could insist that such modules had an
__all__ attribute with appropriate contents]

Why would I want to do that ... and how?
Why: so that you append only the functions that you want to the target
namespace, and don't import stuff like __name__. How: read about
__all__. Just append the stuff that's listed in __all__. However it
sounds like you have seen the light and won't be doing anything like
appending to a namespace.
>
A third: why do you want to import into an existing namespace? Now
that you know about __import__, why just not call the functions where
they are?

Yeah, that would probably be cleaner (safer).
Much cleaner, safer, etc is just to import, or even not to have a
separate module at all.

HTH,
John
Jun 30 '08 #4
John Machin wrote:
On Jun 30, 11:45 am, bvdp <b...@mellowood.cawrote:
>John Machin wrote:

<snip>

Good questions. Short answer ... probably 'cause I've not thought the
problem though completely :)
> You are updating with *everything* in the 'more' module, not just the
functions. This includes such things as __name__, __doc__, __file__.
Could have interesting side-effects.

One quick silly question: why do you want to do this anyway?

I'm writing a "simple" macro expander. I've got some mainline code which
reads an input file, parses out macros, and expands them. So, in my
input file I might have something like:

a fjas j kj sdklj sdkl jfsdkl [ link somewhere sometext ]

So, I need a function link() to evaluate and return "http://...."

Instead of putting funcs like link() in my mainline I've stuck them in a
module of their own.

Why? Do they have any use at all other than to be called by your
mainline?
> In the mainline I

import funcs

and then when I need to expand I have the following code:

Build a dictionary *ONCE*, not each time you want to look in it. E.g.

funcs_vars = vars(funcs)

... much later:

if not cmd in funcs_vars:

>if not cmd in vars(funcs):
error("Unknown function/variable '%s'" % cmd)

if type(vars(funcs)[cmd]) == type(parse):
txt = eval("""funcs.%s("%s")""" % (cmd, arg))

Any particular reason why you are going to the trouble of laboriously
building a statement, compiling it, and running it, when you could
simply do:
txt = funcs_vars[cmd](arg)
?
> else: # not a func, just expand the variable
if arg:
error("Argument to variable '%s' not permitted." % cmd)
txt = str(eval("funcs.%s" % cmd ))

txt = str(funcs_vars[cmd])
>Of course, the question comes up ... what if a user (probably me) wants
to add more functions? Easy enough to just edit funcs.py I suppose, but
I thought it'd be nice to use more modules.

You may already have one more module than you need. If the only thing
different about the extra functions is that they are an afterthought,
then put them in the same module as the others.
>So, I suppose that rather than adding the 2ndary module stuff to the
default 'funcs.py' I could just as well have a look and check for the
needed function in all the modules I've imported.

Sounds quite unnecessary, inefficient and pointless to me.
>>Sorry, *two* quick silly questions: are the add-on modules under your
control, or do you want to be able to do this with arbitrary modules?
[If under your control, you could insist that such modules had an
__all__ attribute with appropriate contents]
Why would I want to do that ... and how?

Why: so that you append only the functions that you want to the target
namespace, and don't import stuff like __name__. How: read about
__all__. Just append the stuff that's listed in __all__. However it
sounds like you have seen the light and won't be doing anything like
appending to a namespace.
>>A third: why do you want to import into an existing namespace? Now
that you know about __import__, why just not call the functions where
they are?
Yeah, that would probably be cleaner (safer).

Much cleaner, safer, etc is just to import, or even not to have a
separate module at all.

HTH,
John
Thanks. Much food for thought here. Let me digest and see what comes of
it all.
Jun 30 '08 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by Torsten Bronger | last post: by
3 posts views Thread by Jim | last post: by
16 posts views Thread by didier.doussaud@gmail.com | last post: by
23 posts views Thread by Shane Hathaway | last post: by
5 posts views Thread by Ian Bicking | last post: by
11 posts views Thread by Brian Blazer | last post: by
49 posts views Thread by Martin Unsal | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.