Dynamically defined functions via exec in imported module

[Nadeem]

Hello all,
I'm trying to write a function that will dynamically generate other
functions via exec. I then want to be able to import the file (module)
containing this function and use it in other modules, but for some
reason it only works using the "import <mod>" syntax, and not "from
<modimport *" syntax... i.e. in the latter case, the function is
dynamically generated, but not accessible from the importing module.
Any ideas on what I can do to be able to retain the second form of
import and still have the exec'd functions visible?

Here's the code... I have three files:

############### ############### #####
# modA.py

def dynamicdef(name , amt):
'''Dynamically defines a new function with the given name that
adds
the given amt to its argument and returns the result.'''
stm = "def %s(x):\n\tretur n x + %d" % (name, amt)
print stm
# exec stm # --- with this, 'name' is only accessible within
this fn
exec stm in globals() # --- this makes it global within this
module...

print eval(name)
dynamicdef('plu s5', 5)

print plus5(7)
############### ############### #####
# modB.py
# This uses the dynamicdef to dynamically define a new function, and
it
# works fine, with the newly defined function being accessible thru
the modA
# module...

import modA

modA.dynamicdef ('plus10', 10)

print help(modA.plus5 )
print help(modA.plus1 0)

print modA.plus5(20)
print modA.plus10(20)

############### ############### #####
# modC.py
# This uses the dynamicdef to dynamically define a new function, but
it
# doesn't work; seems like knowledge of the newly defined function in
the
# modA module is not propagated back to this context or something...?

from modA import *

dynamicdef('plu s10', 10)

print help(plus5)
#print help(plus10) # !!! Fails: NameError: name 'plus10' is not
defined

print plus5(20)
print plus10(20)
############### ############### #####
Thanks for any help/suggestions,
---nadeem

[Michele Simionato]

On Aug 16, 3:25*pm, George Sakkis <george.sak...@ gmail.comwrote:

On Aug 16, 12:50*am, Michele Simionato <michele.simion [e-mail]>
wrote:

The namedtuple recipe by Raymond Hetting does
exactly that and, guess what, it uses exec!

I might be wrong, but the reason namedtuple uses exec is performance.
IIRC earlier versions of the recipe used a metaclass instead, so it's
not that it *has* to use exec, it's just an optimization, totally
justified in this case since namedtuples should be almost as fast as
plain tuples.

I always thought the reason for "exec" was having a good signature in
the namedtuple constructor. I have not
measure performance, though.

[Michele Simionato]

On Aug 16, 4:02*pm, Maric Michaud <ma...@aristote .infowrote:

I'd say that everywhere exec/eval are used in a application/function/lib that
doesn't mean to interpret arbitrary and user provided python code, it is a
bad usage

Problem is, there are things you cannot do without
exec/eval: for instance look at the implementation of
my own decorator module, which uses eval to
guarantee a good signature for the decorated function.
Probably it could be done without exec, with
bytecode hacks, but I regard fiddling with bytecodes
as something worse than exec itself. I am not
sure if in Python 3.0 the signature object is
powerful enough to do the job, I never had to
time to check how it works.

Michele Simionato