Re: Global variables for python applications

Discussion in 'Python' started by James Mills, May 16, 2010.

  1. James Mills

    James Mills Guest

    On Mon, May 17, 2010 at 4:00 AM, Krister Svanlund
    <> wrote:
    > On Sun, May 16, 2010 at 7:50 PM, AON LAZIO <> wrote:
    >>    How can I set up global variables for the entire python applications?
    >> Like I can call and set this variables in any .py files.
    >>    Think of it as a global variable in a single .py file but this is for the
    >> entire application.

    >
    > First: Do NOT use global variables, it is bad practice and will
    > eventually give you loads of s**t.
    >
    > But if you want to create global variables in python I do believe it
    > is possible to specify them in a .py file and then simply import it as
    > a module in your application. If you change one value in a module the
    > change will be available in all places you imported that module in.


    The only place global variables are considered somewhat "acceptable"
    are as constants in a module shared as a static value.

    Anything else should be an object that you share. Don't get into the
    habit of using global variables!

    --james
    James Mills, May 16, 2010
    #1
    1. Advertising

  2. James Mills

    John Nagle Guest

    James Mills wrote:
    > The only place global variables are considered somewhat "acceptable"
    > are as constants in a module shared as a static value.


    Python really ought to have named constants.

    For one thing, it's fine to share constants across threads, while
    sharing globals is generally undesirable. Also, more compile-time
    arithmetic becomes possible.

    Python does have a few built-in named unassignable constants:
    "True", "None", "__debug__", etc. "Ellipsis" is supposed to be a
    constant, too, but in fact you can assign to it, at least through Python 3.1.

    I think there's some religious objection to constants in Python, but
    it predated threading.

    John Nagle
    John Nagle, May 17, 2010
    #2
    1. Advertising

  3. James Mills

    James Mills Guest

    On Mon, May 17, 2010 at 11:57 AM, John Nagle <> wrote:
    >   For one thing, it's fine to share constants across threads, while
    > sharing globals is generally undesirable.  Also, more compile-time
    > arithmetic becomes possible.
    >
    >   Python does have a few built-in named unassignable constants:
    > "True", "None", "__debug__", etc.  "Ellipsis" is supposed to be a
    > constant, too, but in fact you can assign to it, at least through Python
    > 3.1.
    >
    >   I think there's some religious objection to constants in Python, but
    > it predated threading.


    To be honest, classes work just fine for defining constants.
    (Though in my own code I use ALL UPPER CASE variables as it the style).

    --James
    James Mills, May 17, 2010
    #3
  4. On Mon, 17 May 2010 13:34:57 +1000, James Mills wrote:

    > On Mon, May 17, 2010 at 11:57 AM, John Nagle <> wrote:
    >>   For one thing, it's fine to share constants across threads, while
    >> sharing globals is generally undesirable.  Also, more compile-time
    >> arithmetic becomes possible.
    >>
    >>   Python does have a few built-in named unassignable constants:
    >> "True", "None", "__debug__", etc.  "Ellipsis" is supposed to be a
    >> constant, too, but in fact you can assign to it, at least through
    >> Python 3.1.
    >>
    >>   I think there's some religious objection to constants in Python, but
    >> it predated threading.

    >
    > To be honest, classes work just fine for defining constants. (Though in
    > my own code I use ALL UPPER CASE variables as it the style).



    In what way are they constant? Can you not modify them and rebind them?


    --
    Steven
    Steven D'Aprano, May 17, 2010
    #4
  5. On Sun, 16 May 2010 18:57:15 -0700, John Nagle wrote:

    > James Mills wrote:
    >> The only place global variables are considered somewhat "acceptable"
    >> are as constants in a module shared as a static value.

    >
    > Python really ought to have named constants.


    +1

    Unfortunately, it will most likely require new syntax, and semantics.
    While the concept of a constant is pretty straightforward for immutable
    types like ints and strings, what about mutable types?

    And then there's the moratorium, so even if we had agreement on semantics
    and syntax, and a patch, it couldn't be deployed for a few years.



    --
    Steven
    Steven D'Aprano, May 17, 2010
    #5
  6. James Mills

    James Mills Guest

    On Mon, May 17, 2010 at 2:24 PM, Steven D'Aprano
    <> wrote:
    > In what way are they constant? Can you not modify them and rebind them?


    It's just style/convention :)
    Much like _ to denote private variables and methods!

    --james
    James Mills, May 17, 2010
    #6
  7. John Nagle wrote:
    > Also, more compile-time arithmetic becomes possible.


    But only if their values can be computed at compile time. This
    leads to a huge can of worms if you want to be able to import
    named constants from other modules. A large part of what
    currently happens only at run time would have to become
    possible at compile time as well. Either that or so many
    restrictions would have to be placed on the way that the
    values of named constants are specified that they would not
    be very useful in practice.

    > I think there's some religious objection to constants in Python,


    Not religious, but pragmatic. What appears to be a simple and
    obvious idea on the surface turns out not to be nearly so simple
    or obvious in a language as dynamic as Python.

    --
    Greg
    Gregory Ewing, May 17, 2010
    #7
  8. On Mon, 17 May 2010 19:56:15 +1200, Gregory Ewing wrote:

    > John Nagle wrote:
    >> Also, more compile-time arithmetic becomes possible.

    >
    > But only if their values can be computed at compile time.


    John said "more", not "everything imaginable can be calculated at compile
    time" :)

    Python already does constant folding at compile time:


    >>> code = compile('"abc"*2*3', '', 'single')
    >>> dis.dis(code)

    1 0 LOAD_CONST 5 ('abcabcabcabcabcabc')
    3 PRINT_EXPR
    4 LOAD_CONST 3 (None)
    7 RETURN_VALUE



    > This leads to
    > a huge can of worms if you want to be able to import named constants
    > from other modules.



    Why? Once the module is loaded, the named constant is bound to an object.
    Provided that it can't be rebound or mutated, where's the can of worms?


    > A large part of what currently happens only at run
    > time would have to become possible at compile time as well. Either that
    > or so many restrictions would have to be placed on the way that the
    > values of named constants are specified that they would not be very
    > useful in practice.


    I disagree. Enforcing immutability would be tricky, but enforcing once-
    only name binding is relatively simple. There's even a recipe for it in
    the Python Cookbook.




    --
    Steven
    Steven D'Aprano, May 17, 2010
    #8
  9. James Mills

    TomF Guest

    On 2010-05-16 12:27:21 -0700, christian schulze said:

    > On 16 Mai, 20:20, James Mills <> wrote:
    >> On Mon, May 17, 2010 at 4:00 AM, Krister Svanlund
    >>
    >> <> wrote:
    >>> On Sun, May 16, 2010 at 7:50 PM, AON LAZIO <> wrote:
    >>>>    How can I set up global variables for the entire python applications?
    >>>> Like I can call and set this variables in any .py files.
    >>>>    Think of it as a global variable in a single .py file but thisis for the
    >>>> entire application.

    >>
    >>> First: Do NOT use global variables, it is bad practice and will
    >>> eventually give you loads of s**t.

    >>
    >>> But if you want to create global variables in python I do believe it
    >>> is possible to specify them in a .py file and then simply import it as
    >>> a module in your application. If you change one value in a module the
    >>> change will be available in all places you imported that module in.

    >>
    >> The only place global variables are considered somewhat "acceptable"
    >> are as constants in a module shared as a static value.
    >>
    >> Anything else should be an object that you share. Don't get into the
    >> habit of using global variables!
    >>
    >> --james

    >
    > Exactly! Python's OOP is awesome. Use it. Global vars used as anything
    > but constants is bad practice. It isn't that much work to implement
    > that.


    Let's say you have a bunch of globals, one of which is a verbose flag.
    If I understand the difference, using a module gbls.py:
    # in gbls.py
    verbose = False
    # elsewhere:
    import gbls
    gbls.verbose = True

    Using a class:

    # In the main module:
    class gbls(object):
    def __init__(self, verbose=False):
    self.verbose = verbose

    my_globals = gbls.gbls(verbose=True)
    ....
    some_function(my_globals, ...)


    If this is what you have in mind, I'm not really seeing how one is good
    practice and the other is bad. The OOP method is more verbose (no pun
    intended) and I don't see how I'm any less likely to shoot myself in
    the foot with it.

    -Tom
    TomF, May 19, 2010
    #9
  10. On Wed, 19 May 2010 00:16:56 -0700, TomF wrote:

    > Let's say you have a bunch of globals, one of which is a verbose flag.
    > If I understand the difference, using a module gbls.py:
    >
    > # in gbls.py
    > verbose = False
    > # elsewhere:
    > import gbls
    > gbls.verbose = True
    >
    > Using a class:
    >
    > # In the main module:
    > class gbls(object):
    > def __init__(self, verbose=False):
    > self.verbose = verbose
    >
    > my_globals = gbls.gbls(verbose=True)
    > ...
    > some_function(my_globals, ...)
    >
    >
    > If this is what you have in mind, I'm not really seeing how one is good
    > practice and the other is bad. The OOP method is more verbose (no pun
    > intended) and I don't see how I'm any less likely to shoot myself in the
    > foot with it.


    Exactly! Both are considered harmful. Best is to avoid the use of globals
    if possible, not to disguise them by wrapping them in a class.

    The second case (using a class) is slightly less harmful, because you can
    set up multiple global namespaces and do this:

    some_function(my_globals, ...)
    some_function(other_globals, ...)

    which at least allows you to replace the globals on demand, but it is
    still somewhat of a code-smell. Best is to find a way of doing without
    them. (Note that global constants and functions are usually fine.)

    Unfortunately, it's rarely possible to do entirely without global
    settings, except in trivial applications. But what you can do is use
    Python's dynamic programming to reduce the need to keep globals hanging
    around:


    # Untested.
    def verbose_print(arg, level, verbosity=1):
    if level <= verbosity:
    print arg

    def my_function(arg):
    my_print(arg, level=2)
    return arg.upper()

    if __name__ == '__main__':
    if '--verbose' in sys.argv:
    my_print = functools.partial(verbose_print, verbosity=2)
    elif '--quiet' in sys.argv:
    my_print = functools.partial(verbose_print, verbosity=0)

    my_function("hello world")


    Note that although there is no verbosity global setting, every function
    that calls my_print will do the right thing (unless I've got the test
    backwards...), and if a function needs to override the implicit verbosity
    setting, it can just call verbose_print directly.


    --
    Steven
    Steven D'Aprano, May 19, 2010
    #10
  11. James Mills

    TomF Guest

    On 2010-05-19 07:34:37 -0700, Steven D'Aprano said:

    > # Untested.
    > def verbose_print(arg, level, verbosity=1):
    > if level <= verbosity:
    > print arg
    >
    > def my_function(arg):
    > my_print(arg, level=2)
    > return arg.upper()
    >
    > if __name__ == '__main__':
    > if '--verbose' in sys.argv:
    > my_print = functools.partial(verbose_print, verbosity=2)
    > elif '--quiet' in sys.argv:
    > my_print = functools.partial(verbose_print, verbosity=0)
    >
    > my_function("hello world")
    >
    >
    > Note that although there is no verbosity global setting, every function
    > that calls my_print will do the right thing (unless I've got the test
    > backwards...), and if a function needs to override the implicit verbosity
    > setting, it can just call verbose_print directly.
    TomF, May 20, 2010
    #11
    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. Wayne
    Replies:
    2
    Views:
    456
    Wayne
    Nov 11, 2003
  2. praba kar
    Replies:
    2
    Views:
    840
    Paul Rubin
    May 4, 2005
  3. jubelbrus
    Replies:
    5
    Views:
    601
    JohnQ
    Jul 20, 2007
  4. mark4asp
    Replies:
    1
    Views:
    203
  5. Tony Archer

    Global Variables? Multi-Application Variables?

    Tony Archer, Nov 24, 2003, in forum: ASP General
    Replies:
    5
    Views:
    210
    Tony Archer
    Nov 25, 2003
Loading...

Share This Page