Re: Global variables for python applications
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Global variables for python applications
On 2010-05-16 12:27:21 -0700, christian schulze said: On 16 Mai, 20:20, James Mills prolo...@shortcircuit.net.au wrote: On Mon, May 17, 2010 at 4:00 AM, Krister Svanlund krister.svanl...@gmail.com wrote: On Sun, May 16, 2010 at 7:50 PM, AON LAZIO aonla...@gmail.com 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Global variables for python applications
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Global variables for python applications
Steven D'Aprano st...@remove-this-cybersource.com.au wrote: I think it is an abuse of the term constant to allow you to talk about a mutable object being constant, since it can vary. Generally, you don't care about identity, only equality. Making up a syntax on the spot: constant pi = [3.1415] assert pi = 3.1415 pi[0] = 3 assert pi = 3.1415 makes a mockery of the concept of a constant. A better keyword might be something like 'alias' to imply that the name and value are interchangeable. -- Duncan Booth http://kupuguy.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Global variables for python applications
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Global variables for python applications
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
--
http://mail.python.org/mailman/listinfo/python-list
Re: Global variables for python applications
On Mon, 17 May 2010 05:29:20 +0100, Steven D'Aprano ste...@remove.this.cybersource.com.au wrote: 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. Careful, you're reconflating two concepts that John separated: mutability of an object and binding of a name. I'm on the side of 'named constant' meaning 'this name (in this scope) is bound to this object and cannot be rebound.' That would cover most of the cases people care about, and the gotchas are essentially the same as with default arguments. But yes, it would require new syntax. -- Rhodri James *-* Wildebeeste Herder to the Masses -- http://mail.python.org/mailman/listinfo/python-list
Re: Global variables for python applications
2010/5/16 Chris Rebert c...@rebertia.com: On Sun, May 16, 2010 at 10:50 AM, AON LAZIO aonla...@gmail.com wrote: Hi, 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. Thankfully, there is no such thing (can you say spaghetti code?). The closest approximation, as I said in my previous reply, is to use the namespace of a designated module for this purpose, and import that module wherever you need to access/modify these superglobal variables. Example: #g.py: #this module exists to hold superglobal vars global1 = foo global2 = bar #elsewhere.py: #this is some other module in the same program import mypackage.g as g print global #1 = , g.global1 print global #2 =, g.global2 g.global1 = baz # modify a superglobal g.global3 = qux # create a new superglobal Cheers, Chris -- http://blog.rebertia.com -- http://mail.python.org/mailman/listinfo/python-list I agree global variables are evil, but a config.py module within a serie of global constants which are supposed to be shared amongst all other modules is a little less evil, and also a different beast IMO. Even if you use a class to store such data, a global reference to its instance accessible from everywhere must still exist, so the problem basically still stands. I would be interested to know a good practice to solve such a problem. --- Giampaolo http://code.google.com/p/pyftpdlib http://code.google.com/p/psutil -- http://mail.python.org/mailman/listinfo/python-list
Re: Global variables for python applications
On Mon, 17 May 2010 23:54:38 +0100, Rhodri James wrote:
On Mon, 17 May 2010 05:29:20 +0100, Steven D'Aprano
ste...@remove.this.cybersource.com.au wrote:
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.
Careful, you're reconflating two concepts that John separated:
mutability of an object and binding of a name.
In my own head the two issues of mutability and rebinding were completely
separate, but I see now that didn't come through as clearly as I hoped in
my post. My apologies for any confusion.
I'm on the side of
'named constant' meaning 'this name (in this scope) is bound to this
object and cannot be rebound.' That would cover most of the cases
people care about, and the gotchas are essentially the same as with
default arguments.
I think it is an abuse of the term constant to allow you to talk about a
mutable object being constant, since it can vary. Generally, you don't
care about identity, only equality. Making up a syntax on the spot:
constant pi = [3.1415]
assert pi = 3.1415
pi[0] = 3
assert pi = 3.1415
makes a mockery of the concept of a constant.
Having said that, recognising mutable objects is a hard problem, so
simply for reasons of practicality we might have to just live with the
limitation that constants can be mutated if the object supports it.
But yes, it would require new syntax.
Ideally, but there may be alternatives. I've already mentioned the
Cookbook recipe, or perhaps something like:
import constants
constants.register('pi')
pi = 3.1415
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Global variables for python applications
On Mon, May 17, 2010 at 3:50 AM, AON LAZIO aonla...@gmail.com wrote: Hi, 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. If you have to use global variables in your application you are designing it WRONG! Python has powerful support for object orientated programming. Use it! I highly recommend the Python tutorial - especially the section on classes. --James -- http://mail.python.org/mailman/listinfo/python-list
Re: Global variables for python applications
On Sun, May 16, 2010 at 7:50 PM, AON LAZIO aonla...@gmail.com wrote: Hi, 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. Thanks -- Aonlazio 'Peace is always the way.' NW 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Global variables for python applications
On Sun, May 16, 2010 at 10:50 AM, AON LAZIO aonla...@gmail.com wrote: Hi, 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. Thankfully, there is no such thing (can you say spaghetti code?). The closest approximation, as I said in my previous reply, is to use the namespace of a designated module for this purpose, and import that module wherever you need to access/modify these superglobal variables. Example: #g.py: #this module exists to hold superglobal vars global1 = foo global2 = bar #elsewhere.py: #this is some other module in the same program import mypackage.g as g print global #1 = , g.global1 print global #2 =, g.global2 g.global1 = baz # modify a superglobal g.global3 = qux # create a new superglobal Cheers, Chris -- http://blog.rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Global variables for python applications
On Mon, May 17, 2010 at 4:00 AM, Krister Svanlund krister.svanl...@gmail.com wrote: On Sun, May 16, 2010 at 7:50 PM, AON LAZIO aonla...@gmail.com 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Global variables for python applications
On 16 Mai, 20:20, James Mills prolo...@shortcircuit.net.au wrote: On Mon, May 17, 2010 at 4:00 AM, Krister Svanlund krister.svanl...@gmail.com wrote: On Sun, May 16, 2010 at 7:50 PM, AON LAZIO aonla...@gmail.com 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 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Global variables for python applications
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Global variables for python applications
On Mon, May 17, 2010 at 11:57 AM, John Nagle na...@animats.com 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Global variables for python applications
On Mon, 17 May 2010 13:34:57 +1000, James Mills wrote: On Mon, May 17, 2010 at 11:57 AM, John Nagle na...@animats.com 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Global variables for python applications
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Global variables for python applications
On Mon, May 17, 2010 at 2:24 PM, Steven D'Aprano ste...@remove.this.cybersource.com.au 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 -- http://mail.python.org/mailman/listinfo/python-list
