how to create/ref globals in an alternate namespace?

[Steve Holden]

Steven W. Orr wrote:
> On Friday, Apr 27th 2007 at 14:07 -0700, quoth James Stroud:
> 
> =>Steven W. Orr wrote:
> =>> I have two seperate modules doing factory stuff which each have the 
> =>> similar function2:
> =>> 
> =>> In the ds101 module, def DS101CLASS(mname,data):
> =>>     cname = mname+'DS101'
> =>>     msg_class = globals()[cname]
> =>>     msg = msg_class(data)
> =>>     return msg
> =>> 
> =>> and in the fdu module,
> =>> 
> =>> def FDUCLASS(mname,data):
> =>>     cname = mname+'FDU'
> =>>     msg_class = globals()[cname]
> =>>     msg = msg_class(data)
> =>>     return msg
> =>> 
> =>> I was thinking I'd be clever and create a common function:
> =>> def procCLASS(mname, objname, data):
> =>>     cname = mname+objname
> =>>     msg_class = globals()[cname]
> =>>     msg = msg_class(data)
> =>>     return msg
> =>> 
> =>> but the call to globals fouls it all up. Is there a way to write it so 
> =>> that the call to globals can be parameterized to be in the context of a 
> =>> specific module?
> =>> 
> =>> Also, I need to go the other way, a la,
> =>>         globals()[name] = nclass
> =>> 
> =>> Is this doable?
> =>> 
> =>> TIA
> =>> 
> =>
> =>Why do you need all of the msg_class(es) global? Why not put them into a 
> =>module and import the module where you need them? This would be the 
> =>conventional way to avoid such problems.
> 
> The idea is that DS101 is being called in a loop in the ds101 module to 
> create a lot of msg_classes. The same is true for the FDUCLASS function; 
> it creates a lot of classes in a loop.
> 
> In addition, I have two other functions, almost alike, in two seperate 
> modules (mdefs is a structure with all of the stuff needed to drive the 
> loops)
> 
> def __InitDS101Classes():
>     for m in mdefs:
>         mdef = mdefs[m]
>         name = mdefs[m]['name']+'DS101'
>         nclass = new.classobj(name,(DS101,),{})
>         nclass.mdef = mdef
>         nclass.mid = m
>         globals()[name] = nclass
> 
> 
> def __InitFDUClasses():
>     for m in mdefs:
>         mdef = mdefs[m]
>         name = mdefs[m]['name']+'FDU'
>         nclass = new.classobj(name,(FDU,),{})
>         nclass.mdef = mdef
>         nclass.mid = m
>         globals()[name] = nclass
> 
> I'm trying to see if by being clever, I can factor out the common code of 
> the four different functions and still end up with what they create ending 
> up in the namespaces where they are intended to reside in. Does this make 
> sense or am I way off base?
> 
> 
Even if you *can* factor out the common code there's no reason why that 
shouldn't go in a fifth module that the other four import ...

regards
  Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC/Ltd           http://www.holdenweb.com
Skype: holdenweb      http://del.icio.us/steve.holden
------------------ Asciimercial ---------------------
Get Python in your .sig and on the web. Blog and lens
holdenweb.blogspot.com        squidoo.com/pythonology
tag items:            del.icio.us/steve.holden/python
All these services currently offer free registration!
-------------- Thank You for Reading ----------------