how to create/ref globals in an alternate namespace?

Discussion in 'Python' started by Steven W. Orr, Apr 27, 2007.

  1. 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
    Steven W. Orr, Apr 27, 2007
    #1
    1. Advertising

  2. Steven W. Orr

    James Stroud Guest

    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.
    James Stroud, Apr 27, 2007
    #2
    1. Advertising

  3. 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
    Steven W. Orr, Apr 27, 2007
    #3
  4. Steven W. Orr

    alisonken1 Guest

    On Apr 27, 2:33 pm, "Steven W. Orr" <> wrote:
    > On Friday, Apr 27th 2007 at 14:07 -0700, quoth James Stroud:


    <snip>
    >
    > 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.
    alisonken1, Apr 27, 2007
    #4
  5. Steven W. Orr

    James Stroud Guest

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


    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
    James Stroud, Apr 27, 2007
    #5
  6. On Fri, 27 Apr 2007 16:46:24 -0400 (EDT), "Steven W. Orr"
    <> declaimed the following in comp.lang.python:

    > In the ds101 module,


    <snip>

    > 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

    HTTP://wlfraed.home.netcom.com/
    (Bestiaria Support Staff: )
    HTTP://www.bestiaria.com/
    Dennis Lee Bieber, Apr 28, 2007
    #6
  7. Steven W. Orr

    Steve Holden Guest

    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 ----------------
    Steve Holden, Apr 28, 2007
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Chris
    Replies:
    2
    Views:
    667
    Chris
    Mar 4, 2007
  2. Replies:
    0
    Views:
    330
  3. Replies:
    22
    Views:
    739
    peter koch
    Apr 30, 2008
  4. Replies:
    6
    Views:
    332
    James Kanze
    Apr 29, 2008
  5. Replies:
    10
    Views:
    325
    Sean O'Halpin
    Jul 17, 2006
Loading...

Share This Page