how to create/ref globals in an alternate namespace?

[Steven W. Orr]

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

--
Time flies like the wind. Fruit flies like a banana. Stranger things have .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net

 

[James Stroud]

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.

 

[Steven W. Orr]

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?


--
Time flies like the wind. Fruit flies like a banana. Stranger things have .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net

 

[alisonken1]

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?

<snip>

You may be trying to get too clever.

If what you're trying to do is what I think you're trying to do, I
would suggest looking at how the logging module handles globals and
functions for an example.

 

[James Stroud]

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?

If I get your intention, the imported module idea still works:


# imported.py

pass


# module1.py

import imported

imported.abc = 2


# module2.py

import module1
import imported

print imported.abc


James

 

[Dennis Lee Bieber]

In the ds101 module,

and in the fdu module,

<snip>

Where were you two years ago when I had to write a program to accept
GPS PPS keys from a DTD (and everyone was claiming "it's just a serial
port, raw keys"... until the first "live" test with a DTD, where it
became obvious that there was some protocol involved -- at which time a
high-level manager made a few phone calls and I had the protocol specs
delivered... then had three weeks to hack my program to implement an
upside-down HDLC system [upside-down as the code had no recovery
capability; instead of the bottom HDLC level doing asynchronous packet
transfers, decoded by the DS101/FDU logic, and made available to the
top-level logic -- the top-level made calls down requesting specific
FDUs, etc.]).


Okay, enough background noise.

My main suggestion, looking at the <snipped> code would be to NOT
rely on the globals() in existence within the function, but rather to
pass the environment as an additional argument... That way, each
specific module could control what is in the "globals" that were passed
to the general function.

I've not delved too deeply to confirm this will achieve the desired
results, but without trying one won't know...

--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[Steve Holden]

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 ----------------