Re: How should we use global variables correctly?

[Joel Goldstick]

On Fri, Aug 23, 2019 at 4:00 AM Windson Yang  wrote:
>
> Thank you all. I agreed with Frank that
>
> > It would make sense to use the 'global' keyword if you have a module
> with various functions, several of which refer to 'foo', but only one of
> which changes the value of 'foo'.
>
> I also found an example in cpython/lib/gettext.py, only 'textdomain
> function' can change '_current_domain', other functions just refer to it.
> So, it will be not evil or to use 'global' keyword correctly when there is
> only one function can change its value?
>
> Cameron Simpson  于2019年8月23日周五 下午3:15写道：
>

The problem with deciding that only one function can change the value,
is that someone else can change the other functions.  So, if you are
working alone, it won't be a problem, but once code with globals
enters the 'wild' all bets are off.


-- 
Joel Goldstick
http://joelgoldstick.com/blog
http://cc-baseballstats.info/stats/birthdays
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How should we use global variables correctly?

[Windson Yang]

Thank you all. I agreed with Frank that

> It would make sense to use the 'global' keyword if you have a module
with various functions, several of which refer to 'foo', but only one of
which changes the value of 'foo'.

I also found an example in cpython/lib/gettext.py, only 'textdomain
function' can change '_current_domain', other functions just refer to it.
So, it will be not evil or to use 'global' keyword correctly when there is
only one function can change its value?

Cameron Simpson  于2019年8月23日周五 下午3:15写道：

> On 23Aug2019 09:07, Frank Millman  wrote:
> >On 2019-08-23 8:43 AM, Windson Yang wrote:
> >>In class.py
> >>
> >>  class Example:
> >> def __init__(self):
> >> self.foo = 1
> >> def bar()
> >> return self.foo + 1
> >>
> >>Expect the syntax, why using class variable self.foo would be better (or
> >>more common)? I think the 'global' here is relative, foo is global in
> >>global.py and self.foo is global in Example class. If the global.py is
> >>short and clean enough (didn't have a lot of other class), they are
> pretty
> >>much the same. Or I missed something?
> >>
> >
> >One difference is that you could have many instances of Example, each
> >with its own value of 'foo', whereas with a global 'foo' there can
> >only be one value of 'foo' for the module.
>
> But that is an _instance_ attribute. Which is actually what Windson Yang
> made.
>
> A class attribute is bound to the class, not an instance. The
> terminology is important.
>
> Cheers,
> Cameron Simpson 
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How should we use global variables correctly?

[Cameron Simpson]

On 23Aug2019 09:07, Frank Millman  wrote:

On 2019-08-23 8:43 AM, Windson Yang wrote:

In class.py

 class Example:
def __init__(self):
self.foo = 1
def bar()
return self.foo + 1

Expect the syntax, why using class variable self.foo would be better (or
more common)? I think the 'global' here is relative, foo is global in
global.py and self.foo is global in Example class. If the global.py is
short and clean enough (didn't have a lot of other class), they are pretty
much the same. Or I missed something?



One difference is that you could have many instances of Example, each 
with its own value of 'foo', whereas with a global 'foo' there can 
only be one value of 'foo' for the module.


But that is an _instance_ attribute. Which is actually what Windson Yang 
made.


A class attribute is bound to the class, not an instance. The 
terminology is important.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: How should we use global variables correctly?

[Cameron Simpson]

On 23Aug2019 14:43, Windson Yang  wrote:

I also want to know what is the difference between "using 'global
variables' in a py module" and "using a variable in class". For example:

In global.py:

   foo = 1
   def bar():
   global foo
   return foo + 1

In class.py

class Example:
   def __init__(self):
   self.foo = 1
   def bar()
   return self.foo + 1


This isn't a class variable. The .foo attribute will be attached to 
"self", which is an instance of the class, not the class itself.


You probably want:

   class Example2:
   foo = 1
   def __init__(self):
   pass

So what's happening here? When the class is defined, in addition to 
defining the .__init__ method we also define .foo. These are attributes 
of the class: there's just one of each.


In your code you're setting .foo on "self", so there's one per instance 
of the class.


So in my Example2 there's a foo:

 print(Example2.foo)

works.

Compared to a global, this is nicely contained in the class' namespace.  
But otherwise it is the same: it gets defined just once as the module is 
imported (which defines the class Example2, which defines Example2.foo).


However, it _is_ harder to use as a local by accident. Here:

   from example_module import Example2

   z = 1

   def f():
 z = 3
 Example2.foo = 3

Here, "z" is local to "f" because it is assigned to. Example2.foo is 
still the one from inside the class - we're not assigning to a function 
local name, but to a name _accessed_ via Example2.


Expect the syntax, why using class variable self.foo would be better 
(or more common)? I think the 'global' here is relative, foo is global in

global.py and self.foo is global in Example class.


As mentioned, in your Example class self.foo is an attribute of the 
instance, not the class. My Example2 class shows how to put it on the 
class.



If the global.py is
short and clean enough (didn't have a lot of other class), they are pretty
much the same. Or I missed something?


Making a class level name has the nice aspect that it has a better 
conceptual context.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: How should we use global variables correctly?

[Frank Millman]

On 2019-08-23 8:43 AM, Windson Yang wrote:

I also want to know what is the difference between "using 'global
variables' in a py module" and "using a variable in class". For example:

In global.py:

 foo = 1
 def bar():
 global foo
 return foo + 1

In class.py

  class Example:
 def __init__(self):
 self.foo = 1
 def bar()
 return self.foo + 1

Expect the syntax, why using class variable self.foo would be better (or
more common)? I think the 'global' here is relative, foo is global in
global.py and self.foo is global in Example class. If the global.py is
short and clean enough (didn't have a lot of other class), they are pretty
much the same. Or I missed something?



One difference is that you could have many instances of Example, each 
with its own value of 'foo', whereas with a global 'foo' there can only 
be one value of 'foo' for the module.


It would make sense to use the 'global' keyword if you have a module 
with various functions, several of which refer to 'foo', but only one of 
which changes the value of 'foo'.


Frank Millman

--
https://mail.python.org/mailman/listinfo/python-list

Re: How should we use global variables correctly?

[Windson Yang]

I also want to know what is the difference between "using 'global
variables' in a py module" and "using a variable in class". For example:

In global.py:

foo = 1
def bar():
global foo
return foo + 1

In class.py

 class Example:
def __init__(self):
self.foo = 1
def bar()
return self.foo + 1

Expect the syntax, why using class variable self.foo would be better (or
more common)? I think the 'global' here is relative, foo is global in
global.py and self.foo is global in Example class. If the global.py is
short and clean enough (didn't have a lot of other class), they are pretty
much the same. Or I missed something?




Chris Angelico  于2019年8月23日周五 上午9:34写道：

> On Fri, Aug 23, 2019 at 11:24 AM Windson Yang  wrote:
> >
> > Thank you all for the great explanation, I still trying to find some good
> > example to use 'global', In CPython, I found an example use 'global' in
> > cpython/Lib/zipfile.py
> >
> > _crctable = None
> > def _gen_crc(crc):
> > for j in range(8):
> > if crc & 1:
> > crc = (crc >> 1) ^ 0xEDB88320
> > else:
> > crc >>= 1
> > return crc
> >
> > def _ZipDecrypter(pwd):
> > key0 = 305419896
> > key1 = 591751049
> > key2 = 878082192
> >
> > global _crctable
> > if _crctable is None:
> > _crctable = list(map(_gen_crc, range(256)))
> > crctable = _crctable
> >
> > _crctable only been used in the _ZipDecrypter function. IIUC, the code
> can
> > be refactored to
> >
> > def _gen_crc(crc):
> > ...stay the same
> >
> > def _ZipDecrypter(pwd, _crctable=list(map(_gen_crc, range(256:
> > key0 = 305419896
> > key1 = 591751049
> > key2 = 878082192
> >crctable = _crctable
> >
> > Which avoid using 'global' keyword. Why we are not doing this? I guess
> the
> > reason we use 'global' here because we don't want to  create `_crctable =
> > list(map(_gen_crc, range(256)))`  every time when we run '_ZipDecrypter'
> > function. So we kinda cache _crctable with 'global', am I right?
>
> It's a cache that is made ONLY when it's first needed. If you put it
> in the function header, it has to be created eagerly as soon as the
> module is imported.
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How should we use global variables correctly?

[Chris Angelico]

On Fri, Aug 23, 2019 at 11:24 AM Windson Yang  wrote:
>
> Thank you all for the great explanation, I still trying to find some good
> example to use 'global', In CPython, I found an example use 'global' in
> cpython/Lib/zipfile.py
>
> _crctable = None
> def _gen_crc(crc):
> for j in range(8):
> if crc & 1:
> crc = (crc >> 1) ^ 0xEDB88320
> else:
> crc >>= 1
> return crc
>
> def _ZipDecrypter(pwd):
> key0 = 305419896
> key1 = 591751049
> key2 = 878082192
>
> global _crctable
> if _crctable is None:
> _crctable = list(map(_gen_crc, range(256)))
> crctable = _crctable
>
> _crctable only been used in the _ZipDecrypter function. IIUC, the code can
> be refactored to
>
> def _gen_crc(crc):
> ...stay the same
>
> def _ZipDecrypter(pwd, _crctable=list(map(_gen_crc, range(256:
> key0 = 305419896
> key1 = 591751049
> key2 = 878082192
>crctable = _crctable
>
> Which avoid using 'global' keyword. Why we are not doing this? I guess the
> reason we use 'global' here because we don't want to  create `_crctable =
> list(map(_gen_crc, range(256)))`  every time when we run '_ZipDecrypter'
> function. So we kinda cache _crctable with 'global', am I right?

It's a cache that is made ONLY when it's first needed. If you put it
in the function header, it has to be created eagerly as soon as the
module is imported.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How should we use global variables correctly?

[Windson Yang]

Thank you all for the great explanation, I still trying to find some good
example to use 'global', In CPython, I found an example use 'global' in
cpython/Lib/zipfile.py

_crctable = None
def _gen_crc(crc):
for j in range(8):
if crc & 1:
crc = (crc >> 1) ^ 0xEDB88320
else:
crc >>= 1
return crc

def _ZipDecrypter(pwd):
key0 = 305419896
key1 = 591751049
key2 = 878082192

global _crctable
if _crctable is None:
_crctable = list(map(_gen_crc, range(256)))
crctable = _crctable

_crctable only been used in the _ZipDecrypter function. IIUC, the code can
be refactored to

def _gen_crc(crc):
...stay the same

def _ZipDecrypter(pwd, _crctable=list(map(_gen_crc, range(256:
key0 = 305419896
key1 = 591751049
key2 = 878082192
   crctable = _crctable

Which avoid using 'global' keyword. Why we are not doing this? I guess the
reason we use 'global' here because we don't want to  create `_crctable =
list(map(_gen_crc, range(256)))`  every time when we run '_ZipDecrypter'
function. So we kinda cache _crctable with 'global', am I right?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How should we use global variables correctly?

[Richard Damon]

On 8/22/19 12:00 PM, Windson Yang wrote:
> I can 'feel' that global variables are evil. I also read lots of articles
> proves that (http://wiki.c2.com/?GlobalVariablesAreBad). However, I found
> CPython Lib use quite a lot of `global` keyword. So how should we use
> `global` keyword correctly? IIUC, it's fine that we use `global` keyword
> inside the Lib since most of the time the user just import the lib and call
> the API. In any other situation, we should avoid using it. Am I right?

It should be noted that the Python 'global' is much more like the C/C++
file scoped 'static' which is less bad that fully global variables (the
extern variable).


-- 
Richard Damon

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How should we use global variables correctly?

[Chris Angelico]

On Fri, Aug 23, 2019 at 10:18 AM Cameron Simpson  wrote:
> As Michael says, "you can always read from a parent scope if the name
> hasn't been used by the local scope". What this means is this:
>
> _MODULE_LEVEL_CACHE = {}
>
> def factors_of(n):
> factors = _MODULE_LEVEL_CACHE.get(n)
> if factors is None:
> factors = factorise(n)
> _MODULE_LEVEL_CACHE[n] = factors
> return factors

Note that this is still using a global variable, even though it isn't
using the "global" keyword. The two concepts are related but distinct.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How should we use global variables correctly?

[Cameron Simpson]

On 22Aug2019 11:12, Michael Torrie  wrote:

On 8/22/19 10:00 AM, Windson Yang wrote:

I can 'feel' that global variables are evil. I also read lots of articles
proves that (http://wiki.c2.com/?GlobalVariablesAreBad). However, I found
CPython Lib use quite a lot of `global` keyword. So how should we use
`global` keyword correctly? IIUC, it's fine that we use `global` keyword
inside the Lib since most of the time the user just import the lib and call
the API. In any other situation, we should avoid using it. Am I right?


The "global" keyword only refers to the current module as far as I know.
Thus global variables are global only to the current python file, so
the damage, as it were, is limited in scope.


Aye.


And it's only required if
you plan to write to a global variable from another scope; you can
always read from a parent scope if the name hasn't been used by the
local scope.  I'm sure there are use cases for using the global keyword.
It's not evil.  It's just not necessary most of the time.  I don't
think I've ever used the "global" keyword.  If I need to share state, or
simple configuration information, between modules, I place those
variables in their own module file and import them where I need them.


I've used it a few times. Maybe a handful of times in thousands of lines 
of code.


As Michael says, "you can always read from a parent scope if the name 
hasn't been used by the local scope". What this means is this:


   _MODULE_LEVEL_CACHE = {}

   def factors_of(n):
   factors = _MODULE_LEVEL_CACHE.get(n)
   if factors is None:
   factors = factorise(n)
   _MODULE_LEVEL_CACHE[n] = factors
   return factors

   def factorise(n):
   ... expensive factorisation algorithm here ...

Here we access _MODULE_LEVEL_CACHE directly without bothering with the 
global keyword. Because the function "factors_of" does not _assign_ to 
the name _MODULE_LEVEL_CACHE, that name is not local to the function; 
the outer scopes will be searched in order to find the name.


Now, Python decides what variable are local to a function by staticly 
inspecting the code and seeing which have assignments. So:


   x = 9
   y = 10
   z = 11

   function foo(x):
   y = 5
   print(x, y, z)

Within the "foo" function:

- x is local (it is assigned to by the function parameter when you call 
 it)


- y is local (it is assigned to in the function body)

- z is not local (it is not assigned to); the namespace searching finds 
 it in the module scope


Note that in the "factors_of" function we also do not _assign_ to 
_MODULE_LEVEL_CACHE. We do assign to one of its elements, but that is an 
access _via_ _MODULE_LEVEL_CACHE, not an assignment to the name itself.  
So it is nonlocal and found in the module namespace.


However, where you might want the use "global" (or its modern friend 
"nonlocal") is to avoid accidents and to make the globalness obvious.  
The same example code:


   x = 9
   y = 10
   z = 11

   function foo(x):
   y = 5
   print(x, y, z)

When you use a global, that is usually a very deliberate decision on 
your part, because using globals is _usually_ undesirable. When all 
variables are local, side effects are contained within the function and 
some surprises (== bugs) are prevented.


Let's modify "foo":

   function foo(x):
   y = 5
   z = y * 2
   print(x, y, z)

Suddenly "z" is a local variable because it is assigned to.

In this function it is all very obvious because the function is very 
short. A longer function might not have this be so obvious.


So: was "z" still intended to be global?

If yes then you need the global keyword:

   function foo(x):
   global z
   y = 5
   z = y * 2
   print(x, y, z)

And even if we were not assigning to "z", we might still use the 
"global" statement to make it obvious to the reader that "z" is a 
global; after all, if it not very visually distinctive - it looks a lot 
like "x" and "y".


So my advice after all of this is:

As you thought, globals are to be avoided most of the time. They invite 
unwanted side effects and also make it harder to write "pure functions", 
functions with no side effects. Pure functions (most Python functions) 
are much easier to reuse elsewhere.


However, if you have a good case for using a global, always use the 
"global" statement. It has the following benefits: it makes the 
globalness obvious to the person reading the code and it avoids a global 
variable suddenly becoming local if you assign to it. (NB: the "time" of 
that semantic change is when you change the code, _not_ when the 
assignment itself happens.)


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: How should we use global variables correctly?

[Michael Torrie]

On 8/22/19 10:00 AM, Windson Yang wrote:
> I can 'feel' that global variables are evil. I also read lots of articles
> proves that (http://wiki.c2.com/?GlobalVariablesAreBad). However, I found
> CPython Lib use quite a lot of `global` keyword. So how should we use
> `global` keyword correctly? IIUC, it's fine that we use `global` keyword
> inside the Lib since most of the time the user just import the lib and call
> the API. In any other situation, we should avoid using it. Am I right?

The "global" keyword only refers to the current module as far as I know.
 Thus global variables are global only to the current python file, so
the damage, as it were, is limited in scope.  And it's only required if
you plan to write to a global variable from another scope; you can
always read from a parent scope if the name hasn't been used by the
local scope.  I'm sure there are use cases for using the global keyword.
 It's not evil.  It's just not necessary most of the time.  I don't
think I've ever used the "global" keyword.  If I need to share state, or
simple configuration information, between modules, I place those
variables in their own module file and import them where I need them.

-- 
https://mail.python.org/mailman/listinfo/python-list

How should we use global variables correctly?

[Windson Yang]

I can 'feel' that global variables are evil. I also read lots of articles
proves that (http://wiki.c2.com/?GlobalVariablesAreBad). However, I found
CPython Lib use quite a lot of `global` keyword. So how should we use
`global` keyword correctly? IIUC, it's fine that we use `global` keyword
inside the Lib since most of the time the user just import the lib and call
the API. In any other situation, we should avoid using it. Am I right?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Chris Angelico]

On Sat, Nov 16, 2013 at 3:01 PM, Rick Johnson
 wrote:
> Because when i see code that accesses a variable like this:
>
> var = value
>
> I have no way of knowing whether the mutation is happening
> to a local variable, a module level variable, or even a true
> global level variable (one which extends beyond the
> containing module).

If it's in a function, and there's no global/nonlocal declaration,
it's local. Otherwise, it's module level. It can't be process-level in
Python, so you don't need to worry about that.

It doesn't get much simpler than that without variable declarations
(in which case it's "scan surrounding scopes till you find a
declaration, that's it" - and it's arguable whether that's simpler or
not). Really Rick, you're clutching at straws here.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Chris Angelico]

On Sat, Nov 16, 2013 at 3:01 PM, Rick Johnson
 wrote:
> Let's see... Tkinter's design today is a single module
> containing a staggering:
>
> 155,626 chars
>
> 3,733 lines

Also: I see nothing wrong with a single module having 3-4K lines in
it. Hilfe, the Pike REPL/interactive interpreter, is about that long
and it's not a problem to maintain. The Python decimal module (as
opposed to CDecimal) is twice that, in the installation I have here to
check. My primary C++ module from work was about 5K lines, I think -
of that order, at least.

Python modules don't need to be split up into tiny fragments.
Flat is better than nested.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Rick Johnson]

On Friday, November 15, 2013 2:19:01 AM UTC-6, Steven D'Aprano wrote:

> But with software, coupling is *easy*. By default, code in
> a single process is completely coupled. Think of a chunk
> of machine code running in a single piece of memory. We
> have to build in our own conventions for decoupling code:
> subroutines, local variables, objects, modular code, and
> so forth. Physical objects are inherently decoupled. Code
> is inherently coupled, and we need conventions to decouple
> it. One of those conventions is to prefer local variables
> to global variables, and another is to limit the scope of
> global variables to per module rather than process-wide.

You're thoughts on "coupling" and "decoupling"
of design architecture is correct, but you only argue for
your side :-). Allow me to now argue for my side now.

And i want to leave the "safe" world of general analogies
and enter the dark esoteric word of flawed software design.

And since people only want to give me credit when i talk
about Tkinter, well then, what better example of bad design
is there than Tkinter? Hmm, well there's IDLE but that will
have to wait for another thread.

Let's see... Tkinter's design today is a single module
containing a staggering:

155,626 chars

3,733 lines

30 classes 

16 functions

4 "puesdo-constants" (Python does not support true
constants!)

10 "module level" variables (3 of which are mutated from
nested scopes within the module itself)

Unwise use of a global import for the types module, even
though only a few names are used -- AND there are
better ways to test type nowadays!

Unwisely auto-imports 82 Tkinter constants.

Only OpenGL is more promiscuous than Tkinter!  

But let's stay on subject shall we!


  The Road To Recovery:


The very first thing a wise programmer would do is create a
package called "tkinter". Then, he would export all class
source code to individual sub-modules -- each module being
the class name in lowercase.

AND VOILA! 

Even after only a simple half hour of restructuring, the
code is starting to become maintainable -- IMAGINE THAT!


BUT DON'T GET YOUR ASTROGLIDE OUT YET FELLA! 

WE'VE GOT MORE WORK TO DO!

Just as the programmer thought "all was well" in "toon
town", he quickly realizes that since Python has no
intelligent global variable access, and his sub-modules need
to share data with the main tkinter module (and vise versa),
he will be forced to write:

from tkinter import var1, var2, ..., varN

IN EVERY DAMN SUBMODULE that needs to access or
mutate one of the shared variables or shared
functions.

Can anyone tell me why sharing globals between sub-packages
is really so bad that we have to import things over and
over?

And if so, would you like to offer a cleaner solution for
the problem? 

And don't give me the messy import thing, because that's 
not elegant!

WHY IS IT NOT ELEGANT RICK?

Because when i see code that accesses a variable like this:

var = value

I have no way of knowing whether the mutation is happening
to a local variable, a module level variable, or even a true
global level variable (one which extends beyond the
containing module).

Sure, i could search the file looking for imports or
global declarations, but why not use "self documenting
paths" to global variables?

The best solution is to create a global namespace. You could
name it "G". So when i see a mutation like this:

G.var = value:

I will know that the mutation is happening to a REAL global
variable. But, even that information is lacking. I need
more... What i really want to see is this:

G.tkinter.var = value
  
Boom baby! Every thing i need to know is contained within
that single line without "import everywhere".

   I am accessing a global variable
   I am accessing a global variable for the tkinter package
   The variable's name is "var"
  
It's explicit, but it's not SO explicit that it becomes
excessive, no. I would much rather type just a FEW more
characters than scour source code looking for obscure clues
like global declarations, imports, or whatever foolish
design you can pull out of your arse!

And what about the mysterious "run-time injected
global", how the heck are you planning to handle
that one with imports?

I just want to access globals in an logical and consistent
manner via a clean interface which will alleviate all the
backtracking and detective work that causes us to lose focus
on the main architecture of our software.

Because,

EXPLICIT IS BETTER THAN IMPLICIT.
 

Re: PyMyth: Global variables are evil... WRONG!

[Tim Daneliuk]

On 11/15/2013 09:42 AM, Chris Angelico wrote:

On Sat, Nov 16, 2013 at 2:26 AM, Tim Daneliuk  wrote:

On 11/15/2013 02:19 AM, Steven D'Aprano wrote:

Nobody sets out to*design*  a tangled mess. What normally happens is that
a tangled mess is the result of*lack of design*.


This has been an interesting thread - to me anyway - but this bit
above caught my eye.  People write programs for lots of reasons -
personal, academic, scientific, and commercial - but I actually
don't thing the resultant messes are caused by a "lack of
design" most of the time.  In my experience they're caused by only two
things:

2) An evolving set of requirements.


This can be an explanation for a lack of design, but it's no less a
lack. Sometimes, something just grows organically... from a nucleus of
good design, but undesigned growth. Maybe it's time it got redesigned;
or maybe redesigning would take too much effort and it's just not
worth spending that time on something that's going to be phased out by
the next shiny thing in a couple of years anyway. Doesn't change the
fact that the current state is not the result of design, but of
disorganized feature creep. That's not necessarily a terrible thing,
but Steven's point still stands: such lack of design often results in
a tangled mess, and a tangled mess can often be blamed on lack of
design.

ChrisA



A fair point.  Perhaps a better way to say this would be "Code that
is a tangled mess is often so because good design was not possible
during its creation."

The problem, of course, is that in almost all circumstances there is usually
not a lot of economic benefit to redesign and restructure the code
once you *do* know the requirements.  Other projects compete for attention
and fixing old, ugly stuff rarely gets much attention.  This is particularly
true insofar as most organizations do a lousy job of tracking what it
is really costing them to operate that kind of code.  If they did, cleaning
things up would become a much bigger priority.

Oh, and inevitably, the person that wrote the code without stable requirements
and without being given time to go back, refactor, cleanup, and restructure the
code ... gets blamed by the people that have to run and maintain it.



Years ago I worked for a company that did embedded banking software that
ran on high speed check readers.  It was an "application" that had been
undergoing constant feature creep and change during about an 18 month period
because the woman in marketing running the program get getting
Bright New Ideas (tm) to peddle.

The programmer - frustrated by this - began adding increasingly direct,
personal, and biological comments about said marketing person in the
comments of his assembler code.  Anyway, the new feature requests finally
stopped, and she came in one day to briskly inform us that the code
had been sold to one of our customers and she'd need a tape by end of
week.  The guy who'd been writing all this turned sheet white and scrambled
over the next few days to expunge all his nasty comments from thousands
of lines of assembler.  It was most entertaining to watch ...

--

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

--
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Tim Daneliuk]

On 11/15/2013 02:19 AM, Steven D'Aprano wrote:

Nobody sets out to*design*  a tangled mess. What normally happens is that
a tangled mess is the result of*lack of design*.


This has been an interesting thread - to me anyway - but this bit
above caught my eye.  People write programs for lots of reasons -
personal, academic, scientific, and commercial - but I actually
don't thing the resultant messes are caused by a "lack of
design" most of the time.  In my experience they're caused by only two things:

1) A lack of skill by inexperienced programmers who've been
   given more to do than they're yet ready to do and whose
   senior colleagues are not mentoring them (or such mentoring
   is being rejected because of ego and/or politics).

2) An evolving set of requirements.

#2 is particularly prevalent in commercial environments.  Modern
business is forced to respond to changing commercial conditions
in nearly realtime these days.   The pace of required innovation is
fast that - all too often - no one actually knows what the "requirements"
are during the design phase.  Requirements get *discovered* during the
coding phase.  This is not a moral failing or lack of discipline, it's
the simple reality that what you thought you needed to deliver changed
in the intervening 6 months of coding because the business changed.

 


Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

--
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Chris Angelico]

On Sat, Nov 16, 2013 at 2:26 AM, Tim Daneliuk  wrote:
> On 11/15/2013 02:19 AM, Steven D'Aprano wrote:
>> Nobody sets out to*design*  a tangled mess. What normally happens is that
>> a tangled mess is the result of*lack of design*.
>
> This has been an interesting thread - to me anyway - but this bit
> above caught my eye.  People write programs for lots of reasons -
> personal, academic, scientific, and commercial - but I actually
> don't thing the resultant messes are caused by a "lack of
> design" most of the time.  In my experience they're caused by only two
> things:
>
> 2) An evolving set of requirements.

This can be an explanation for a lack of design, but it's no less a
lack. Sometimes, something just grows organically... from a nucleus of
good design, but undesigned growth. Maybe it's time it got redesigned;
or maybe redesigning would take too much effort and it's just not
worth spending that time on something that's going to be phased out by
the next shiny thing in a couple of years anyway. Doesn't change the
fact that the current state is not the result of design, but of
disorganized feature creep. That's not necessarily a terrible thing,
but Steven's point still stands: such lack of design often results in
a tangled mess, and a tangled mess can often be blamed on lack of
design.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Steven D'Aprano]

On Thu, 14 Nov 2013 09:26:18 -0800, Rick Johnson wrote:

> On Wednesday, November 13, 2013 11:50:40 PM UTC-6, Steven D'Aprano
> wrote:
[...]
>> of course, but that in general *its too damn hard* for human
>> programmers to write good, reliable, maintainable, correct (i.e.
>> bug-free) code using process-wide global variables.
> 
> Complete FUD. Maybe for you. Not for me.

I wasn't taking about genius programmers like you Rick, that would be 
silly. I'm talking about mere mortals like the rest of us.


>> Global variables are the spaghetti code of namespacing -- everything is
>> mixed up together in one big tangled mess.
> 
> It's a tangled mess if you design it to be a tangled mess.

Nobody sets out to *design* a tangled mess. What normally happens is that 
a tangled mess is the result of *lack of design*.


>> The more global variables you have, the worse the tangle.
> 
> Complete illogic.
> 
> What if all the globals are only accessed and never mutated? 

Then they aren't global VARIABLES. You'll note that I was very careful to 
refer to "variables".

Read-only global constants don't increase coupling to anywhere near the 
same degree as writable global variables. As such, they're far less 
harmful.

Of course, there is still some degree of coupling -- suppose one chunk of 
code wants a global constant X=23 and another chunk of code wants a 
global constant X=42? But such issues are generally easy to spot and easy 
to fix.


>> One or two is not too bad. With good conventions for encapsulation to
>> limit the amount of tangled, coupled code (e.g. naming conventions, or
>> limiting globals to a single module at a time by default) the amount of
>> harm can be reduced to manageable levels.
> 
>> SO now your agreeing that globals are not evil again.

In this thread, I have never called global variables "evil". I have 
called them *harmful*, and tried to make it clear that harm is not a 
dichotomy "zero harm" versus "infinite harm", but a matter of degree. I 
stand by that.


>> Global variables increases coupling between distant parts of the code.
>> I remember a nasty little bug in Windows where removing IE stopped
>> copy-and- paste from working everywhere. That's a sign of excess
>> coupling between code -- there's no logical reason why removing a web
>> browser should cause copying text in Notepad to fail.
> 
> Do you have link describing this bug? I am not aware of such bug ,but
> uh, i would not at all be surprised that windows could break from
> removing that gawd awful IE.
> 
> Come to think of it, i'll bet it's not even a bug at all, but a feature
> to prevent "wise users" from removing IE, thereby maintaining IE's
> footprint in the wild.

Heh. 

Sorry, I can't find the link. It was well over five years ago, probably 
more like ten. But whether deliberate or accidental, that's the sort of 
thing I mean when I talk about excessive coupling. Note that coupling in 
and of itself is not harmful -- for example, you want the brake pedal of 
your car to be coupled to the brakes. Excess and inappropriate coupling 
is harmful: pressing the brake pedal shouldn't turn off the headlights, 
nor should a blown brake light stop the brakes from working. Hence we try 
to minimize coupling to only those areas that actually need them.

With physical devices, that's often -- not always -- trivial. The 
constraints of physical matter makes it natural to keep things loosely 
coupled. When you're building a car, the hard part is getting the 
coupling that you actually do want, not avoiding coupling you don't. 
Physical devices are, as a general rule, inherently and naturally 
encapsulated: the brake pedal is physically uncoupled from the brakes 
unless you literally connect them with steel cables and wires. Your 
fridge isn't connected to anything except the power supply, so it 
physically can't flush the toilet. Since the toilet and fridge are made 
in different factories and installed by different people, there's no 
motivation to couple them. Even if some bright spark decided that since 
opening the fridge door turns on the fridge light, and pressing the 
toilet button opens the cistern value, the two operations are related and 
therefore "Don't Repeat Yourself" applies and there should be a single 
mechanism to do both, it is impractical to build such a system. (And 
thank goodness. But just wait until we have internet-enabled fridges and 
toilets...)

But with software, coupling is *easy*. By default, code in a single 
process is completely coupled. Think of a chunk of machine code running 
in a single piece of memory. We have to build in our own conventions for 
decoupling code: subrouti

Re: PyMyth: Global variables are evil... WRONG!

[Chris Angelico]

On Fri, Nov 15, 2013 at 7:12 AM, Alister  wrote:
> Ricks non trolling posts do give him enough credibility to avoid
> dismissing his ideas out of hand

When he's talking about Tkinter, he knows his stuff, and is orders of
magnitude more helpful than I would be (as I don't know Tkinter). When
he's talking about warts in Python, he sometimes knows what he's
talking about, often ignores facts, and generally is more stirring the
pot than actually being productive. But hey, they can still be fun
threads.

Now, I'm just waiting for the thread in which Nikos has problems with
Tkinter not working with Greek characters as of Python 3.3, and a
singularity is formed that results in the destruction of the known
universe...

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Alister]

On Thu, 14 Nov 2013 09:56:04 -0800, Ethan Furman wrote:

> On 11/14/2013 09:37 AM, Joel Goldstick wrote:
>>
>> So, beyond that, what is the point of the thread?
> 
> You haven't met Ranting Rick yet?  He's a troll's troll, outdone only by
> one other whose name I don't remember.
> 
> His posts are, amazingly enough, rants.  Usually about his
> (mis)perceptions of the failures of:
> 
>- Python - The Python Leaders - Good Coding Practices - Everyone but
>himself (and the "Silent Majority" he represents)
> 
> He has been on vacation for a few months, but, alas, he is back. 
> Interestingly, even though he is still in my kill file I could tell the
> thread was his just from the subject title.

I don't think there is any comparison.
Ricks trolls do at least promote intelligent discussion & cause the 
reader to re-asses preconceptions if only to confirm them.

Ricks non trolling posts do give him enough credibility to avoid 
dismissing his ideas out of hand





-- 
Go away! Stop bothering me with all your "compute this ... compute that"!
I'm taking a VAX-NAP.

logout
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Mark Lawrence]

On 14/11/2013 17:56, Ethan Furman wrote:

On 11/14/2013 09:37 AM, Joel Goldstick wrote:


So, beyond that, what is the point of the thread?


You haven't met Ranting Rick yet?  He's a troll's troll, outdone only by
one other whose name I don't remember.

His posts are, amazingly enough, rants.  Usually about his
(mis)perceptions of the failures of:

   - Python
   - The Python Leaders
   - Good Coding Practices
   - Everyone but himself (and the "Silent Majority" he represents)

He has been on vacation for a few months, but, alas, he is back.
Interestingly, even though he is still in my kill file I could tell the
thread was his just from the subject title.

--
~Ethan~


But he's not 100% troll as he has published some useful stuff on 
IDLE/tkinter, that's why he's only on the subs bench for my Trolls Dream 
Team.  No guesses who the captain is now :)


--
Python is the second best programming language in the world.
But the best has yet to be invented.  Christian Tismer

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Joel Goldstick]

On Thu, Nov 14, 2013 at 12:56 PM, Ethan Furman  wrote:
> On 11/14/2013 09:37 AM, Joel Goldstick wrote:
>>
>>
>> So, beyond that, what is the point of the thread?
>
>
> You haven't met Ranting Rick yet?  He's a troll's troll, outdone only by one
> other whose name I don't remember.
>
> His posts are, amazingly enough, rants.  Usually about his (mis)perceptions
> of the failures of:
>
>   - Python
>   - The Python Leaders
>   - Good Coding Practices
>   - Everyone but himself (and the "Silent Majority" he represents)
>
> He has been on vacation for a few months, but, alas, he is back.
> Interestingly, even though he is still in my kill file I could tell the
> thread was his just from the subject title.
>
> --
> ~Ethan~
> --
> https://mail.python.org/mailman/listinfo/python-list

Ah, thanks.  A tag team .. oh my!

-- 
Joel Goldstick
http://joelgoldstick.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Ethan Furman]

On 11/14/2013 09:37 AM, Joel Goldstick wrote:


So, beyond that, what is the point of the thread?


You haven't met Ranting Rick yet?  He's a troll's troll, outdone only by one 
other whose name I don't remember.

His posts are, amazingly enough, rants.  Usually about his (mis)perceptions of 
the failures of:

  - Python
  - The Python Leaders
  - Good Coding Practices
  - Everyone but himself (and the "Silent Majority" he represents)

He has been on vacation for a few months, but, alas, he is back.  Interestingly, even though he is still in my kill file 
I could tell the thread was his just from the subject title.


--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Joel Goldstick]

On Thu, Nov 14, 2013 at 12:26 PM, Rick Johnson
 wrote:
> On Wednesday, November 13, 2013 11:50:40 PM UTC-6, Steven D'Aprano wrote:
>> On Wed, 13 Nov 2013 19:45:42 -0800, Rick Johnson wrote:
>> > On Wednesday, November 13, 2013 8:45:16 PM UTC-6, Steven D'Aprano wrote:
>> >>  A fully-auto machine gun with a hair-trigger and no
>> >> safety is no  different from a single-barrel shotgun with a safety and
>> >> a trigger lock!  You can blow your foot off with both!
>> > Yes. But in the case of the shotgun you'd have to find the key, unlock
>> > the trigger, unset the safety, and aim REALLY well... because your only
>> > getting off one shot, and if you miss or only wound me, i've got that
>> > full auto machine gun with hair trigger and no safety -- i won't need to
>> > live very long to return the favor. >:)
>> I think you're missing the point that we're talking about the coder
>> shooting themselves in the foot, not Gunfight At The OK Corral. There's
>> no "favour" to return.
>
> And you missed the point that i took your straw-man and
> converted him into satire. You owe me gratitude for
> *politely* ignoring your repeated logical fallacies.
>
>> Yes, the point is that process-wide global variables are
>> demonstrated by 50+ years of programming experience to be
>> best avoided (in general -- there are caveats and
>> exceptions of course). We're talking about probably
>> millions of person-hours of experience leading to the
>> conclusion that "globals are harmful".
>
> But yet Python has globals, you just have to *import* them.
> But that design is flawed
>
>> It isn't that global variables will leap out of the
>> computer and attack you while you sleep,
>
> Funny, that sounds like my argument from earlier. Something
> about "gremlins".
>
>> of course, but that in general *its too damn hard* for
>> human programmers to write good, reliable, maintainable,
>> correct (i.e. bug-free) code using process-wide global
>> variables.
>
> Complete FUD. Maybe for you. Not for me.
>
>> Global variables are the spaghetti code of namespacing --
>> everything is mixed up together in one big tangled mess.
>
> It's a tangled mess if you design it to be a tangled mess.
>
>> The more global variables you have, the worse the tangle.
>
> Complete illogic.
>
> What if all the globals are only accessed
> and never mutated? You could have a million globals that never
> change (of course they'd technically be constants) and never
> suffer a single error from globals EVEN IF your an incompetent
> software designer.
>
>> One or two is not too bad. With good conventions for
>> encapsulation to limit the amount of tangled, coupled code
>> (e.g. naming conventions, or limiting globals to a single
>> module at a time by default) the amount of harm can be
>> reduced to manageable levels.
>
>> SO now your agreeing that globals are not evil again. I
>> positied an anaology in a passed thred that went something
>> like this:
>
> ManufacurerA claims his car is the safest on the road.
>
> ManfacturerB drives ManfacturerA's car into a ditch and then
> claims ManfacturerA is a liar.
>
> Result: Who is wrong?
>
>> Global variables increases coupling between distant parts
>> of the code. I remember a nasty little bug in Windows
>> where removing IE stopped copy-and- paste from working
>> everywhere. That's a sign of excess coupling between code
>> -- there's no logical reason why removing a web browser
>> should cause copying text in Notepad to fail.
>
> Do you have link describing this bug? I am not aware of such
> bug ,but uh, i would not at all be surprised that windows
> could break from removing that gawd awful IE.
>
> Come to think of it, i'll bet it's not even a bug at all,
> but a feature to prevent "wise users" from removing IE,
> thereby maintaining IE's footprint in the wild.
>
> Steven, this sounds more like Fascism than "clumsy use of
> globals" to me.
>
> But even IF globals are to blame, by removing IE, you have
> removed a large chunk of code from a code base that was not
> designed for modularity. (We could argue whether or not
> windows should allow removal of IE, but ultimately that is
> M$ decision)
>
> No developer could possibly forecast every possible "bad
> thing" a user might decide to do. Especially when we're
> talking about ripping components of the software out
> completely.
>
> Do i think IE should

Re: PyMyth: Global variables are evil... WRONG!

[Rick Johnson]

On Wednesday, November 13, 2013 11:50:40 PM UTC-6, Steven D'Aprano wrote:
> On Wed, 13 Nov 2013 19:45:42 -0800, Rick Johnson wrote:
> > On Wednesday, November 13, 2013 8:45:16 PM UTC-6, Steven D'Aprano wrote:
> >>  A fully-auto machine gun with a hair-trigger and no
> >> safety is no  different from a single-barrel shotgun with a safety and
> >> a trigger lock!  You can blow your foot off with both!
> > Yes. But in the case of the shotgun you'd have to find the key, unlock
> > the trigger, unset the safety, and aim REALLY well... because your only
> > getting off one shot, and if you miss or only wound me, i've got that
> > full auto machine gun with hair trigger and no safety -- i won't need to
> > live very long to return the favor. >:)
> I think you're missing the point that we're talking about the coder 
> shooting themselves in the foot, not Gunfight At The OK Corral. There's 
> no "favour" to return. 

And you missed the point that i took your straw-man and
converted him into satire. You owe me gratitude for
*politely* ignoring your repeated logical fallacies.

> Yes, the point is that process-wide global variables are
> demonstrated by 50+ years of programming experience to be
> best avoided (in general -- there are caveats and
> exceptions of course). We're talking about probably
> millions of person-hours of experience leading to the
> conclusion that "globals are harmful".

But yet Python has globals, you just have to *import* them.
But that design is flawed

> It isn't that global variables will leap out of the
> computer and attack you while you sleep,

Funny, that sounds like my argument from earlier. Something
about "gremlins".

> of course, but that in general *its too damn hard* for
> human programmers to write good, reliable, maintainable,
> correct (i.e. bug-free) code using process-wide global
> variables.

Complete FUD. Maybe for you. Not for me.
 
> Global variables are the spaghetti code of namespacing --
> everything is mixed up together in one big tangled mess.

It's a tangled mess if you design it to be a tangled mess. 

> The more global variables you have, the worse the tangle. 

Complete illogic. 

What if all the globals are only accessed
and never mutated? You could have a million globals that never
change (of course they'd technically be constants) and never
suffer a single error from globals EVEN IF your an incompetent
software designer.

> One or two is not too bad. With good conventions for
> encapsulation to limit the amount of tangled, coupled code
> (e.g. naming conventions, or limiting globals to a single
> module at a time by default) the amount of harm can be
> reduced to manageable levels.

> SO now your agreeing that globals are not evil again. I
> positied an anaology in a passed thred that went something
> like this:

ManufacurerA claims his car is the safest on the road.

ManfacturerB drives ManfacturerA's car into a ditch and then
claims ManfacturerA is a liar.

Result: Who is wrong?

> Global variables increases coupling between distant parts
> of the code. I remember a nasty little bug in Windows
> where removing IE stopped copy-and- paste from working
> everywhere. That's a sign of excess coupling between code
> -- there's no logical reason why removing a web browser
> should cause copying text in Notepad to fail.

Do you have link describing this bug? I am not aware of such
bug ,but uh, i would not at all be surprised that windows
could break from removing that gawd awful IE.

Come to think of it, i'll bet it's not even a bug at all,
but a feature to prevent "wise users" from removing IE,
thereby maintaining IE's footprint in the wild. 

Steven, this sounds more like Fascism than "clumsy use of
globals" to me.

But even IF globals are to blame, by removing IE, you have
removed a large chunk of code from a code base that was not
designed for modularity. (We could argue whether or not
windows should allow removal of IE, but ultimately that is
M$ decision)

No developer could possibly forecast every possible "bad
thing" a user might decide to do. Especially when we're
talking about ripping components of the software out
completely.

Do i think IE should be a removal component? HECK YEAH, and
i would have designed it that way. But IS is not my baby, it
belongs to Mr. Gates, and he designs his software any way he
damn well pleases, and you and i can choose not to use it.

Image if someone downloaded Python and just started ripping
out source files willy-nilly because they did not like them
for whatever reason. Then, they came to this list and start
bitching because Python was blowing chunks. And don't give
examples of things that can be

Re: PyMyth: Global variables are evil... WRONG!

[unknown]

On Thu, 14 Nov 2013 14:29:41 +1100, Chris Angelico wrote:

> On Thu, Nov 14, 2013 at 2:22 PM, Rick Johnson
>  wrote:
>> Yeah, a "global" keyword that extends access ONLY as far as module
>> level scope -- hardly a *true* global.
> 
> I have yet to see any language that gives true globals. At very best,
> they're just process-wide! Honestly. How am I supposed to write code
> that accesses variables running on my New York server?
> 
> Now, of course, if I had a server on Mars, that would be completely
> different. They're only globals, after all.
> 
> ChrisA

+ networking computers on Mars is impossible (with TCP/IP at least)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Steven D'Aprano]

On Wed, 13 Nov 2013 23:33:22 -0500, Roy Smith wrote:

> In article ,
>  Chris Angelico  wrote:
> 
>> I have yet to see any language that gives true globals. At very best,
>> they're just process-wide! Honestly. How am I supposed to write code
>> that accesses variables running on my New York server?
> 
> Any one of a slew of remote procedure call protocols.  These days, the
> cool kids are using REST, but people have been doing RPC-ish things ever
> since the first guy to connect two computers with a piece of wire.

Nice Devil's Advocacy :-)

But of course, there are differences between the two situations. In a RPC, 
you have to use a defined interface to reach across the wire, so to 
speak, rather than have the two machines intimately coupled in a single 
namespace.

It is true that you can write RPC code that is highly coupled. Such 
highly coupled code is harmful whether it occurs due to global variables 
or via RPC calls or some other mechanism. But the difference is you have 
to work at it to write such highly coupled code with RPC calls, while 
with single-process globals such coupling occurs naturally without effort.


-- 
Steven
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Steven D'Aprano]

On Wed, 13 Nov 2013 19:45:42 -0800, Rick Johnson wrote:

> On Wednesday, November 13, 2013 8:45:16 PM UTC-6, Steven D'Aprano wrote:
>>  A fully-auto machine gun with a hair-trigger and no
>> safety is no  different from a single-barrel shotgun with a safety and
>> a trigger lock!  You can blow your foot off with both!
> 
> Yes. But in the case of the shotgun you'd have to find the key, unlock
> the trigger, unset the safety, and aim REALLY well... because your only
> getting off one shot, and if you miss or only wound me, i've got that
> full auto machine gun with hair trigger and no safety -- i won't need to
> live very long to return the favor. >:)

I think you're missing the point that we're talking about the coder 
shooting themselves in the foot, not Gunfight At The OK Corral. There's 
no "favour" to return. 


>> Yes, but in the first case you can do it by accident, while with the 
>> second you have to work hard to blow your foot off.
> 
> Uh huh.
> 
> And why do i have the sneaking suspicion that the BIG SCARY ASSAULT
> WEAPON is referring to my argument and the "old shot-gun that Grandpa
> has in the closet under lock and key" is your argument.

That's the most insightful observation you've made in this thread so far.

Yes, the point is that process-wide global variables are demonstrated by 
50+ years of programming experience to be best avoided (in general -- 
there are caveats and exceptions of course). We're talking about probably 
millions of person-hours of experience leading to the conclusion that 
"globals are harmful".

It isn't that global variables will leap out of the computer and attack 
you while you sleep, of course, but that in general *its too damn hard* 
for human programmers to write good, reliable, maintainable, correct 
(i.e. bug-free) code using process-wide global variables. Global 
variables are the spaghetti code of namespacing -- everything is mixed up 
together in one big tangled mess.

The more global variables you have, the worse the tangle. One or two is 
not too bad. With good conventions for encapsulation to limit the amount 
of tangled, coupled code (e.g. naming conventions, or limiting globals to 
a single module at a time by default) the amount of harm can be reduced 
to manageable levels.

Global variables increases coupling between distant parts of the code. I 
remember a nasty little bug in Windows where removing IE stopped copy-and-
paste from working everywhere. That's a sign of excess coupling between 
code -- there's no logical reason why removing a web browser should cause 
copying text in Notepad to fail. We want to avoid unnecessary coupling: 
opening your fridge door shouldn't flush the toilet.

Since global variables increase coupling, and coupling is often harmful, 
one way to avoid unnecessary coupling is to avoid unnecessary global 
variables. Think of them as leaches. Even today, there are good uses for 
medical leaches:

http://en.wikipedia.org/wiki/Hirudo_medicinalis


One or two leaches is hardly noticeable. Ten or twenty starts being a bit 
of a problem. A few dozen and you'll certainly notice, and if you're 
covered in multiple hundreds of them, you're at risk of dying from blood 
loss, never mind the risk of infection.


-- 
Steven
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Chris Angelico]

On Thu, Nov 14, 2013 at 3:33 PM, Roy Smith  wrote:
> In article ,
>  Chris Angelico  wrote:
>
>> I have yet to see any language that gives true globals. At very best,
>> they're just process-wide! Honestly. How am I supposed to write code
>> that accesses variables running on my New York server?
>
> Any one of a slew of remote procedure call protocols.  These days, the
> cool kids are using REST, but people have been doing RPC-ish things ever
> since the first guy to connect two computers with a piece of wire.
>
> Wait, aren't you the guy who's into MUDs?

Yeah, I am. But there's this annoying difficulty with accessing
variables. I have to send messages around the world and get responses
back, I can't just type "global foo" and have foo be the same thing
here and everywhere else. I mean, it's called "global" for a reason,
why can't it be the same "foo" for every single process in the world?

Or if it's okay for "globals" to not be globally shared, then why is
it a problem for them to be per-module?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Rick Johnson]

On Wednesday, November 13, 2013 10:33:22 PM UTC-6, Roy Smith wrote:
> Wait, aren't you the guy who's into MUDs?

Yes he is. 

But that's his second favorite hobby. 

His first is filling the "Devils Advocate" slot when 
Steven is too busy -- doing WHATEVER Steven does when 
he's not here. God only knows.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Roy Smith]

In article ,
 Chris Angelico  wrote:

> I have yet to see any language that gives true globals. At very best,
> they're just process-wide! Honestly. How am I supposed to write code
> that accesses variables running on my New York server?

Any one of a slew of remote procedure call protocols.  These days, the 
cool kids are using REST, but people have been doing RPC-ish things ever 
since the first guy to connect two computers with a piece of wire.

Wait, aren't you the guy who's into MUDs?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Rick Johnson]

And what's this?

*picks up hat*

Where did this hat come from???

Spectator interrupts: Maybe Steven threw his hat in?

No, no. 

Can't be. 

Steven would not wear something this old. 

I mean, it looks like something a farmer would put on a
scarecrow or something???

*scratched head*

OH MY GAWD!

*throws hat on floor*

That hat has crow poop on it!

Could someone PLEASE get a janitor in here to clean this
mess up! 

For Christs sakes we're trying to have a technical
discussion here and some prankster goes and tosses a
straw grenade right in the middle of it!

How rude!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Rick Johnson]

On Wednesday, November 13, 2013 8:45:16 PM UTC-6, Steven D'Aprano wrote:
>  A fully-auto machine gun with a hair-trigger and no
> safety is no  different from a single-barrel shotgun with
> a safety and a trigger lock!  You can blow your foot off
> with both!  

Yes. But in the case of the shotgun you'd have to find the
key, unlock the trigger, unset the safety, and aim REALLY
well... because your only getting off one shot, and if you
miss or only wound me, i've got that full auto machine gun
with hair trigger and no safety -- i won't need to live very
long to return the favor. >:)

> Yes, but in the first case you can do it by
> accident, while with the  second you have to work hard to
> blow your foot off.

Uh huh. 

And why do i have the sneaking suspicion that the BIG SCARY
ASSAULT WEAPON is referring to my argument and the "old
shot-gun that Grandpa has in the closet under lock and key"
is your argument.

But more importantly, why is all this straw scattered across
the floor? 

Very strange.

Very strange indeed.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Chris Angelico]

On Thu, Nov 14, 2013 at 2:22 PM, Rick Johnson
 wrote:
> Yeah, a "global" keyword that extends access ONLY as far as
> module level scope -- hardly a *true* global.

I have yet to see any language that gives true globals. At very best,
they're just process-wide! Honestly. How am I supposed to write code
that accesses variables running on my New York server?

Now, of course, if I had a server on Mars, that would be completely
different. They're only globals, after all.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Rick Johnson]

On Wednesday, November 13, 2013 7:09:42 PM UTC-6, Steven D'Aprano wrote:
> On Wed, 13 Nov 2013 23:42:24 +, Rhodri James wrote:
> > On Tue, 12 Nov 2013 02:06:09 -, Rick Johnson wrote:
> >> Python has globals, but we just can't admit it!
> > A different subject entirely, but no more accurately stated.
> Completely inaccurately stated. It certainly isn't true
> that "99%" of people  claim that Python has no globals.
> That would be a stupid thing to say for a language with a
> "global" keyword, 

Yeah, a "global" keyword that extends access ONLY as far as
module level scope -- hardly a *true* global.

> a "globals" function, 

Yeah, a "globals function" that returns the MODULE LEVEL
globals symbol table.

> and a built-in module that is shared across the entire
> process.

Now your thinking clearly. This is where Python's dirty
little "secret globals" live.

> Just because a module global alpha.spam is accessible to
> anything that imports the module doesn't make it a
> process-wide global. The ability to do this: import alpha
> alpha.spam = 23 does not make "spam" a process-wide
> global.

Oh lord, back to the fuzzy logic again :(
 
> It just means that attribute access on the module object
> is the supported interface for manipulating names in
> namespaces which are modules.

HUH? Was this last sentence an attempt to distract? We are
all quite aware that DOT access is the interface for
accessing module members, but what the hell does that have
to do with "process wide globals"?

No, your not going to so easily fool this audience with
slight of hand! In your generalized code example:

import alpha
alpha.spam = 23

Yes. "spam" is an attribute of module "alpha", however, it is
also a global variable. Why?
 
  BECAUSE "alpha.spam" CAN BE MUTATED FROM ANYWHERE!

> There is very little practical difference apart from
> convenience between directly manipulating attributes as
> above, and using a setter function like "setattr(alpha,
> 'spam', 23)". Python tries to avoid boilerplate.

Here you go again. Steven, we are ALL quite aware of these
facts, how is "setattr" germane to my complaints about globals?

> Since manipulating attributes is useful, a philosophy of
> consenting adults applies and we have direct access to
> those attributes, 

We don't have "direct access", but access is an import away.

> with an understanding that we should use this power with
> care. With great power comes great responsibility -- if
> you're going to reach inside another module and manipulate
> things, you ought to know what you're doing.

Yes we must be careful, because these attributes are
ACTUALLY global. The fact that you have to use an import
statement to reach them does not alter the fact that they are
globally mutable.

> One of the
> numerous problems with process-wide globals is that
> there's no encapsulation and consequently one package's
> use of "spam" clobbers another package's use of "spam" for
> a different purpose. 

Exactly. That's why globals should be used intelligently.
There are many methods of creating an intelligent ordering
of global names so they don't clash. One of the most
simplistic is to tag all names with a prefix.

The best method is to have a namespace for globals that is
available everywhere WITHOUT import and accessed via a
single letter (you could emulate this now in Python by
injecting a namespace into sys.modules). In this manner,
globals will be both easily accessible, qualified (no need
for prefixes), and available WITHOUT messy imports

> But that's not the case here: alpha's "spam" is separate
> from module omega's "spam" variable. To give an analogy:
> [snip analogy]

Steven you're going off into "la-la land" man. Are you
suggesting that because two modules can contain the same
name that module attributes are not global?

I love how you support the duck typing paradigm UNTIL it
interferes with your argument. Sure, under Python's current
implementation of "globally mutable module attributes" you
can have the same name stored in different modules all with
different values, but they're still GLOBALS!

Because I can reach in and access them OR mutate them from
ANYWHERE! That's the very definition of a "globally
accessible variable" (aka: global variable)

AND THIS IS WERE THE HYPOCRISY COMES IN. 

Since python modules have no set/get interface restrictions,
ALL attributes are globals!


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Steven D'Aprano]

On Wed, 13 Nov 2013 18:10:59 -0800, Rick Johnson wrote:

> On Wednesday, November 13, 2013 5:42:24 PM UTC-6, Rhodri James wrote:
>> On Tue, 12 Nov 2013 02:06:09 -, Rick Johnson wrote:
>> > PyMyth: Global variables are evil... WRONG!
>> That's not a PyMyth.  It's a CompSciMyth, or to be more accurate a good
>> general Software Engineering guideline regardless of language.  Like
>> all guidelines it can be broken, but people who break it should do so
>> knowingly, aware that they have created potential problems for
>> themselves.
> 
> You speak as if using globals are inhabited by gremlins just wanting to
> get out and run a muck. There are no "inherent" problems in the global
> interface design except those that programmer inserts himself.
> 
> Real global variable interfacing is no different than python object
> member interfacing, or module interfacing, except that the latter two
> are encapsulated by inside a namespace, and the former (historically)
> are unprotected and available everywhere; hence the name "global" :-)

A fully-auto machine gun with a hair-trigger and no safety is no 
different from a single-barrel shotgun with a safety and a trigger lock! 
You can blow your foot off with both!

Yes, but in the first case you can do it by accident, while with the 
second you have to work hard to blow your foot off.


> So that renders this whole argument of "global gremlins" as FUD. The
> gremlins don't exist until the programmer creates them.

Wait... are you saying that software bugs only occur because the coder 
writes buggy software? I thought bugs came into existence via spontaneous 
generation, like viruses, bacteria, pigeons and Marine Corps sergeants.


> And i also want to point out the hypocrisy of Python's design. Python
> DOES have globals

Is that why it has a global keyword and a globals() function? Thanks for 
the information, I never would have worked that out without your keen 
insight.


-- 
Steven
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Rick Johnson]

On Wednesday, November 13, 2013 6:17:22 PM UTC-6, Tim Daneliuk wrote:
> > But python modules can't be interfaces because interfaces
> > should protect internal data, prevent external forces from
> > meddling with internal state (EXCEPT via the rules of a
> > predefined "contract"), hide dirty details from the caller,
> > and have clearly defined access points.
> >BUT PYTHON MODULES DON'T FOLLOW THIS DESIGN PATTERN!
> I think this is an unfair criticism.   You can do this in
> ANY language if you know how.  For example, if I understand
> stack frames, I can write code that fiddles with local
> variables in compiled code.  For that matter, if I understand
> pointers at the assembler level, I can probably do the same
> with globals.

And if i understand file systems, and i have access to your
computer, i can delete the contents of your hard disc :-). We
can take this analogy all the way to it's absurd conclusions,
but we have not proven anything.

> Programming well has far less to do with the language and
> has far more to do with the designer and coder...

I very much agree. 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Rick Johnson]

On Wednesday, November 13, 2013 4:00:15 PM UTC-6, Andrew Cooper wrote:
> And what do you do when the wizards bend space-time to
> make PI exactly 3, for the ease of other calculations when
> building a sorting machine?

Are you telling me that these wizards can't be bothered to
write the integer "3"? They have to reassign math.pi instead?

Look if you need some other granularity of PI besides
what's offered in math.PI, then do your own calculation.

The last thing you want to do is create a variable when a
constant is what you need.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Rick Johnson]

On Wednesday, November 13, 2013 5:42:24 PM UTC-6, Rhodri James wrote:
> On Tue, 12 Nov 2013 02:06:09 -, Rick Johnson wrote:
> > PyMyth: Global variables are evil... WRONG!
> That's not a PyMyth.  It's a CompSciMyth, or to be more
> accurate a good general Software Engineering guideline
> regardless of language.  Like all guidelines it can be
> broken, but people who break it should do so knowingly,
> aware that they have created potential problems for
> themselves.

You speak as if using globals are inhabited by gremlins
just wanting to get out and run a muck. There are no
"inherent" problems in the global interface design except
those that programmer inserts himself.

Real global variable interfacing is no different than
python object member interfacing, or module interfacing,
except that the latter two are encapsulated by inside a
namespace, and the former (historically) are unprotected and
available everywhere; hence the name "global" :-)

With Python, i can still reassign a value to class attribute
and break code that depends on that attribute, of course,
doing so is not a good idea; but it's allowed nonetheless!

The programmer can break ANY interface in Python, be it
accessing a module attribute he shouldn't touch or via a
"real global" variable (if Python had that functionality).

So that renders this whole argument of "global gremlins" as
FUD. The gremlins don't exist until the programmer creates
them. Just because one programmer is unable to create a
logical global implementation, does not mean another cannot.

All you need to do is adopt the principles of consistency.

But i'm not here to convince you that globals are correct
for you, nor do i want you to use them if you feel
uncomfortable (lord knows there's enough bad code
circulating already!) i just want people to stop propagating
this myth that globals are evil.

And i also want to point out the hypocrisy of Python's
design. Python DOES have globals


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Steven D'Aprano]

On Wed, 13 Nov 2013 23:42:24 +, Rhodri James wrote:

> On Tue, 12 Nov 2013 02:06:09 -, Rick Johnson
>  wrote:
> 
>> PyMyth: Global variables are evil... WRONG!
> 
> That's not a PyMyth.  It's a CompSciMyth, or to be more accurate a good
> general Software Engineering guideline regardless of language.

To be precise, it's not a myth at all.

Just because there are occasional medical uses for digitalis doesn't make 
it a myth that it is deadly poison. Just because there are occasional 
programming uses for global variables doesn't make it a myth that they 
are poor practice and lead to hard-to-maintain, unsafe, buggy code.


> Like all
> guidelines it can be broken, but people who break it should do so
> knowingly, aware that they have created potential problems for
> themselves.

Absolutely correct.


>> 
>>  The denial of the 99%:
>>  Python has
>> globals, but we just can't admit it!
> 
> A different subject entirely, but no more accurately stated.

Completely inaccurately stated. It certainly isn't true that "99%" of 
people (who exactly? Rick doesn't say) claim that Python has no globals. 
That would be a stupid thing to say for a language with a "global" 
keyword, a "globals" function, and a built-in module that is shared 
across the entire process.


> [snip]
>> But even the "module level" globals can be accessed "globally" if the
>> module they are contained in is imported everywhere.
> 
> Remember when I said that guidelines can be broken?

I think you know the following, but for anyone else reading...

Just because a module global alpha.spam is accessible to anything that 
imports the module doesn't make it a process-wide global. The ability to 
do this:

import alpha
alpha.spam = 23

does not make "spam" a process-wide global. It just means that attribute 
access on the module object is the supported interface for manipulating 
names in namespaces which are modules.

There is very little practical difference apart from convenience between 
directly manipulating attributes as above, and using a setter function 
like "setattr(alpha, 'spam', 23)". Python tries to avoid boilerplate. 
Since manipulating attributes is useful, a philosophy of consenting 
adults applies and we have direct access to those attributes, with an 
understanding that we should use this power with care. With great power 
comes great responsibility -- if you're going to reach inside another 
module and manipulate things, you ought to know what you're doing.

One of the numerous problems with process-wide globals is that there's no 
encapsulation and consequently one package's use of "spam" clobbers 
another package's use of "spam" for a different purpose. But that's not 
the case here: alpha's "spam" is separate from module omega's "spam" 
variable.

To give an analogy: just because I can walk through the door of number 23 
Alpha Street and rummage through their fridge, and walk through the door 
of number 42 Omega Road and do the same, doesn't mean that the two 
fridges are actually the same fridge.



-- 
Steven
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Tim Daneliuk]

On 11/11/2013 10:46 PM, Rick Johnson wrote:

On Monday, November 11, 2013 8:47:09 PM UTC-6, Tim Daneliuk wrote:

I think this is certainly the use case most people would
suggest. But I think you may have missed the real reason
most modern designers object to inter-module globals:  The
presence of such entities almost always means the code has
been designed badly.  Whether we're writing pristine OO
code (cough, cough) or more traditional procedural stuff,
information hiding is a good thing.


Yes, and i agree. But you cannot "hide" everything. There
will always be a need to share information.


When and where there is a need for modules (or programs,
or machines, or "clouds", or interstellar space ...) to
share information, my view is this is better done via some
sort of interface/message passing mechanism.


But python modules can't be interfaces because interfaces
should protect internal data, prevent external forces from
meddling with internal state (EXCEPT via the rules of a
predefined "contract"), hide dirty details from the caller,
and have clearly defined access points.

   BUT PYTHON MODULES DON'T FOLLOW THIS DESIGN PATTERN!



I think this is an unfair criticism.   You can do this in
ANY language if you know how.  For example, if I understand
stack frames, I can write code that fiddles with local
variables in compiled code.  For that matter, if I understand
pointers at the assembler level, I can probably do the same
with globals.

Global access/visibility is a matter of convenience - it's harder
to do in a static compiled language and easier to do in a
late bound, dynamic language.   The fact that this is
*possible* in Python doesn't speak to Python's fitness for
any particular purpose nor does it speak to whether globals
are a good- or bad idea.  Anyone that knows enough to fiddle
with the internal implementation of a module and or subvert
global constants like math.pi, also know what they're doing
is "perverse" and have to be willing to live with the side
effects and consequences of such acts.

I cut my teeth in this business writing realtime machine control
software in assembly language (and PL/M!) where there was NO
memory protection and everything - code, data, stack - was
"global" in some sense, or at least could be made to be.
We managed to routinely write highly reliable, blazingly
fast code that didn't break, didn't bork, and did what it
was supposed to.   There's no reason to believe that Python
programs cannot do the exact same thing (well, not the realtime
part) with just as much robustness and correctness as those
old asm programs.

Programming well has far less to do with the language and has
far more to do with the designer and coder...



Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

--
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Mark Lawrence]

On 13/11/2013 23:42, Rhodri James wrote:

On Tue, 12 Nov 2013 02:06:09 -, Rick Johnson
 wrote:


PyMyth: Global variables are evil... WRONG!


That's not a PyMyth.  It's a CompSciMyth, or to be more accurate a good
general Software Engineering guideline regardless of language.  Like all
guidelines it can be broken, but people who break it should do so
knowingly, aware that they have created potential problems for themselves.



A quote from a colleage of mine circa 1991 "Real time programming is 
easy, just make all the data global".  There you are everybody, problem 
solved :)


--
Python is the second best programming language in the world.
But the best has yet to be invented.  Christian Tismer

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Rhodri James]

On Tue, 12 Nov 2013 02:06:09 -, Rick Johnson  
 wrote:



PyMyth: Global variables are evil... WRONG!


That's not a PyMyth.  It's a CompSciMyth, or to be more accurate a good  
general Software Engineering guideline regardless of language.  Like all  
guidelines it can be broken, but people who break it should do so  
knowingly, aware that they have created potential problems for themselves.




 The denial of the 99%:

Python has globals, but we just can't admit it!


A different subject entirely, but no more accurately stated.

[snip]

But even the "module level" globals can be accessed
"globally" if the module they are contained in is imported
everywhere.


Remember when I said that guidelines can be broken?


Globals are justified when they are used to communicate
information between scopes that otherwise were meant to be
mutually exclusive. One good example would be package sub-
modules.


Sometimes, yes.  As long as you don't mind not being thread-safe, etc,  
etc.  If you've designed your interface, you're probably fine.  If you've  
throw it together with globals because it's the easy way, you're about to  
find out why the guideline you're breaking is a good one.



 "But Rick, even when we use globals, we don't need that many"

Only if you consider the single package that represents your
program, but what about the thousands of support libraries
with millions of lines of code that work in the background
to make your measly few thousand lines of code work?  What
about all the globals that they have injected?


Didn't you just say that Python globals are really module-level globals?   
Isn't this a strawman you've already disallowed?  It sounds to me like  
you're complaining that Python is ahead of the curve here :-)


--
Rhodri James *-* Wildebeest Herder to the Masses
--
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Andrew Cooper]

On 13/11/2013 02:45, Rick Johnson wrote:
> 
> "math.pi" should be "math.PI". and PI should be a CONSTANT. 
> And not just a pseudo constant, but a REAL constant that 
> cannot be changed.
> 

And what do you do when the wizards bend space-time to make PI exactly
3, for the ease of other calculations when building a sorting machine?

Does usenet start delivering these posts in the past/future?

I suspect real python programmers will be able to feel quite smug when
they can change the value of math.pi to suit the situation.

~Andrew

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Tim Chase]

On 2013-11-12 18:45, Rick Johnson wrote:
> "math.pi" should be "math.PI".

It's a real shame that this fails:

  >>> math.PI = math.pi

oh...wait...

> and PI should be a CONSTANT. And not just a pseudo constant, but a
> REAL constant that cannot be changed.

How much precision do you want?  Perhaps you really do want do just
use because you know you only have 2-3 places of precision in your
other numbers:

  math.pi = 3.14

Or maybe you want to monkey-patch in a fraction/decimal instead for
greater precision:

 math.pi = 
decimal.Decimal('3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679')

It comes back to Python being a language for consenting adults.

-tkc



-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Rick Johnson]

On Tuesday, November 12, 2013 4:41:34 PM UTC-6, jongiddy wrote:
> On Tuesday, November 12, 2013 5:00:37 PM UTC, Rick Johnson wrote: 
> >1. Accept that globals are useful, and make them
> >   available through a "real" global syntax, not
> >   some attribute of a module that "appears" to be
> >   local, but in reality is global. Then prevent
> >   external mutation of module attributes directly,
> >   and instead, require that mutation must follow a
> >   contract defined by internal module "setter"
> >   functions.
> >2. Remain convinced that global mutation is evil
> >   and prevent mutation of all python module
> >   attributes. You can import modules, but you can't
> >   mutate their contents.
> From your first post, I take it you're not keen on option #2.

That is correct, i prefer to use REAL interfaces.

> For #1, module globals are exactly the hierarchically
> namespaced globals that you desire in your first post,

Agreed.

> except they are variables, not get/set handlers (which is
> what I take you to mean by an "interface"). 

Yes, python modules expose ALL members publicly and have no
support for contractual interfacing.

> Why not create a PEP to provide handlers for module
> attributes? You could base it on PEP 213, which describes
> the same feature for classes. 

I would love to see modules expand to something more than
mere "boxes to stuff variables". But then again, modules
are not going to provide the ease of access that globals
demand due to the import problem.

Modules will not be a good place to store globals because
modules must be imported and globals should never need
importing. 

I've just released a module on Python-list called "G.py"
that does exactly what i propose. It's not perfect, but i
think you'll understand what i'm proposing after testing 
it.

> As a bonus, this would trivially support option #2 (e.g.
> non-mutable math.pi) by raising an exception for the set
> operator.

"math.pi" should be "math.PI". and PI should be a CONSTANT. 
And not just a pseudo constant, but a REAL constant that 
cannot be changed.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Terry Reedy]

On 11/11/2013 11:46 PM, Rick Johnson wrote:


No, Python modules can be poked, prodded, and violated by
any pervert who can spell the word "import".


Or by clever programmers.


Attribute values can be reassigned and state can be
externally manipulated


Perhaps for good reasons.


resulting in all types of undefined behaviors


Not necessarily. Manipulation can also eliminate undefined behaviors.

Suppose I want to test a Idle function that uses a tkinter.messagebox 
class to communicate with users. Perhaps the module has


from tkinter.messagebox import askretrycancel

The behavior of askretrycancel(*args) is undefined insofar as it depends 
on the arbitrary actions of a human user (it may even hang forever). In 
an automated test, there is no user, and it is difficult to simulate the 
eyes and fingers of one while leaving askretrycancel as it is. 
Monkeypatching with a mock solves this. Simplifying a bit, and leaving 
out details, I have done something like this.


from mock_tkinter import mbox  # mocks all messageboxes
mock_arc = mbox()
import mod
mod.askretrycancel = mock_arc

This makes mod.askretrycancel deterministic in that I can preload a 
response into mock_arc before calling the function or method in mod. 
(This simulates a user's fingers.) The mock also saves the values sent 
to it to see if they are what they should be. (This simulates a user's 
eyes.)


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[jongiddy]

On Tuesday, November 12, 2013 5:00:37 PM UTC, Rick Johnson wrote: 
> 
> 
>1. Accept that globals are useful, and make them
> 
>   available through a "real" global syntax, not
> 
>   some attribute of a module that "appears" to be
> 
>   local, but in reality is global. Then prevent
> 
>   external mutation of module attributes directly,
> 
>   and instead, require that mutation must follow a
> 
>   contract defined by internal module "setter"
> 
>   functions.
> 
> 
> 
>2. Remain convinced that global mutation is evil
> 
>   and prevent mutation of all python module
> 
>   attributes. You can import modules, but you can't
> 
>   mutate their contents.

>From your first post, I take it you're not keen on option #2.

For #1, module globals are exactly the hierarchically namespaced globals that 
you desire in your first post, except they are variables, not get/set handlers 
(which is what I take you to mean by an "interface").

Why not create a PEP to provide handlers for module attributes? You could base 
it on PEP 213, which describes the same feature for classes.

As a bonus, this would trivially support option #2 (e.g. non-mutable math.pi) 
by raising an exception for the set operator.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Rick Johnson]

On Tuesday, November 12, 2013 11:00:37 AM UTC-6, Rick Johnson wrote:
[snip]
> We have all been brainwashed by authorities. First they
> give us rules, then they give us the power to break
> those rules. 

The devil himself said it best:

  http://www.youtube.com/watch?v=RGR4SFOimlk

Hmm. How do we humans cope with all these opposing rules? If
we created an AI with all the ridiculous, convoluted and
opposing rules that we humans live with on a daily basis, it
would blow chunks.

How do our minds possibly cope with such illogical rules
without blowing chunks?

We cope by re-inventing reality.  We cope by convincing
ourselves that truths are not true and lies are true.

We cope by designing languages that obfuscate globals behind
pseudo interfaces so we can get farm fuzzy feelings in our
tummy, then we can "secretly" break the rule when non-one is
looking.

By doing this we convince ourselves that we are "pure".

HUMANS: What a pathetic bunch of slaves!

 http://www.youtube.com/watch?v=PFdmAgA_Gfo


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Tim Chase]

On 2013-11-12 09:00, Rick Johnson wrote:
> Because the constant PI should never change. Sure we can
> argue about granularity of PI, but that argument has no
> weight on the fact that PI should be a constant.
> 
> By placing PI in the module "math", we are creating a pseudo
> interface. We (the creators) are "assuming" that PI will be a
> constant and never change, and the caller is assuming that
> pi will remain static,  but not only can it be mutated, it
> can be mutated globally.

But the module-scoping of "globals" is perfectly valid:

 >>> print(math.PI)
 3.1415926535897932
 >>> print(Magnum.PI)
 "Tom Selleck"

As an example from the stdlib of setting globals via a protocol,
locale.setlocale() does exactly this.  So I'm not sure why you have
your knickers in a knot.  Module-level items can be accessed
globally (though often a bad idea, or at least you have to beware of
side-effects where other things might break), and if you don't like
the "modules are not objects", someone in this thread already showed
you that you can insert objects/classes into the sys.modules and get
full getter/setter functionality with minimal trouble.

Finally, we're all (mostly) consenting adults here.  If I want to be
an idiot and

  math.PI = 3.14

and suddenly stuff breaks, I get to keep all the pieces my breakage
caused.

-tkc



-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Rick Johnson]

On Tuesday, November 12, 2013 9:33:50 AM UTC-6, jongiddy wrote:
> I'm not sure where you get the feeling you're accessing an
> interface.

Because the constant PI should never change. Sure we can
argue about granularity of PI, but that argument has no
weight on the fact that PI should be a constant.

By placing PI in the module "math", we are creating a pseudo
interface. We (the creators) are "assuming" that PI will be a
constant and never change, and the caller is assuming that
pi will remain static,  but not only can it be mutated, it
can be mutated globally.

math.pi is neither a constant nor a local module attribute,
math.pi is really a global variable. This is true not only
for math.pi, but ALL attributes of ALL python modules.

> If I typed this, I would feel like I was trying
> to change a fundamental constant. You have just
> demonstrated that going into other modules and changing
> their attributes (whether they are variables, functions or
> classes) is generally a BAD idea, and I don't think I've
> ever seen anyone recommend doing this, except possibly as
> a workaround or for debugging purposes. On the other hand,
> you initially suggested that modifying globals contained
> within namespaces (i.e. modules) is a good way to
> communicate between modules.

You missed my point: only IF python modules were TRUE
interfaces. It's not a good idea under python's current
implementation of modules. My thread is intended to
underscore this very design flaw.

> This inconsistency

There is no inconsistency in my logic, quite the contrary.

I think you're having difficulty following along because
you've been brainwashed by Python for too long. You've
falsely believed that Python does not have globals, but
it does! You just have to mutate then via a pseudo
interface.

> is why I was asking for a good example (i.e.
> a realistic example where the use of global variables
> provides the best solution).

I gave a good example in my very first post:

RR: "Globals are justified when they are used to
[share] information between scopes that otherwise
were meant to be mutually exclusive. One good
example would be package sub-modules."

> Just because a tool allows you to do something does not
> make it a good idea. Try this paraphrase of your last
> post: Ladder designers act like standing on the top rung
> is SO evil, but then they give us ladders with a top rung,
> Are they just trying to fool themselves, or fool us?

EXACTLY. And whilst your comparison is both intelligent and
funny, you're just re-iterating my point!

We have all been brainwashed by authorities. First they
give us rules, then they give us the power to break
those rules. If standing on the top rung is SO
dangerous, then don't manufacture your ladders with top
rungs. Else, shut up about it!

  "THOU SHALT NOT KILL"

Well i can't live WITH the B!@$%!!!

  "THOU SHALT NOT COMMIT ADULTERY"

Then why create me with a unquenchable desire for sex?

  "THOU SHALT NOT TAKE THE LORDS NAME IN VAIN"

GOD DAMMIT! Stop making all these opposing rules.

So the designers detest globals huh? But python module
attributes are really global because they can be accessed
and mutated ANYWHERE!". This enigma leads to two logical
design philosophies: (anything else is folly)

   1. Accept that globals are useful, and make them
  available through a "real" global syntax, not
  some attribute of a module that "appears" to be
  local, but in reality is global. Then prevent
  external mutation of module attributes directly,
  and instead, require that mutation must follow a
  contract defined by internal module "setter"
  functions.

   2. Remain convinced that global mutation is evil
  and prevent mutation of all python module
  attributes. You can import modules, but you can't
  mutate their contents.

THIS IS HOW YOU DESIGN FOR CONSISTENCY, NOT HYPOCRISY!

@LanguageDesigners: But whatever you do, don't hide globals
behind pseudo interfaces, because then you have created
something worse than a global; you've created a global in
sheep's clothing. And you're a hypocrite.


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[jongiddy]

On Tuesday, November 12, 2013 3:05:25 PM UTC, Rick Johnson wrote:
> 
> 
> 
> When i type "math.pi", i "feel" as though i'm accessing an
> 
> interface, BUT I'M NOT! 

I'm not sure where you get the feeling you're accessing an interface. If I 
typed this, I would feel like I was trying to change a fundamental constant.

You have just demonstrated that going into other modules and changing their 
attributes (whether they are variables, functions or classes) is generally a 
BAD idea, and I don't think I've ever seen anyone recommend doing this, except 
possibly as a workaround or for debugging purposes.

On the other hand, you initially suggested that modifying globals contained 
within namespaces (i.e. modules) is a good way to communicate between modules. 
That is, you suggested in your initial post that going into other modules and 
changing their attributes is a GOOD idea.

This inconsistency is why I was asking for a good example (i.e. a realistic 
example where the use of global variables provides the best solution).

Just because a tool allows you to do something does not make it a good idea. 
Try this paraphrase of your last post: Ladder designers act like standing on 
the top rung is SO evil, but then they give us ladders with a top rung, Are 
they just trying to fool themselves, or fool us? 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Chris Angelico]

On Wed, Nov 13, 2013 at 1:32 AM, Alister  wrote:
> As an analogy music has may general rules that musicians are wise to
> follow.
> Some pieces of music that break these rules are great because they have
> broken the rules but most are not. those that are great are great because
> the musician in question understands the reasons for the rules & how
> breaking them will affect the end product, the ones that are bad are
> because the musician does not know enough about music to even know the
> rule exists.

Agreed. Pieces of music that violate the rules arbitrarily are just
annoying to try to play (and nearly impossible for the church to
follow), but when you find those really brilliant pieces that do
something special (Sir Arthur Sullivan, I'm looking at you -
especially having just been reading the booklet that came with the new
Beauty Stone recording), it's magnificent.

Global variables basically don't exist in Python. You have per-module
state. And if you start monkey-patching, you're fiddling with someone
else's module. It's all fun and games till someone loses a function...

sys.stdout.write=None

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Rick Johnson]

On Tuesday, November 12, 2013 8:12:10 AM UTC-6, jongiddy wrote:

> Can you please give an example where having a module
> provide a global variable would work better than any of:
> [snip]

Well my point is that the attributes of any Python module
are "emulating" globals already. The fact that we have to
mutate them via a "psuedo" interface makes us "falsely"
believe we are using an interface -- but we aren't!

 PYTHON MADE ACCESSING GLOBAL VARIABLES MORE DIFFICULT!

As example. I could import the math module and start
fiddling with attributes. Let's say for example i can change
the value of math.pi. Most people would probably say "what's
the problem with that?", here, let me show you.

# mod1.py
print "mod1.py"
import math
math.pi = "tasty"

# mod2.py
print "mod2.py"
import math
print ' value of math.pi is:', math.pi
radius = 10
math.pi * radius

#modmain.py
import mod1
import mod2
print dir(mod1)
print dir(mod2)

When you run "modmain.py" you will see that not only have we
changed the global variable "pi" to a string, but thanks to
a dumb overloading of the multiply operator, python will
happily give use the wrong answer -- but that's another
problem, let's stay focused on the "global" problem for now!

When i type "math.pi", i "feel" as though i'm accessing an
interface, BUT I'M NOT! If i was indeed accessing a TRUE
interface, the interface would have thrown a Type error for
attempting to assign a value of type string to what should
only be a float. The interface would have protected it's
internal data from corruption, but it didn't.

  BECAUSE IT'S NOT AN INTERFACE!

It's just a dumb namespace with no exposed hooks to control
it's underlying behavior.

  MY POINT IS:

Python designers act like globals are SO evil, but then they
give us modules which are containers for global variables,
and now the globals contained within those modules are
wolves in sheep's clothing. Are they just trying to fool
themselves, or fool us?

  FOOD FOR THOUGHT:

What's worse? A wolf? Or a wolf in sheep's clothing?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Alister]

On Mon, 11 Nov 2013 18:06:09 -0800, Rick Johnson wrote:

> 
> In this thread, i want to get to the bottom of this whole
> "global-phobia" thing once and for all, and hopefully help you folks
> understand that globals are not all that bad -- when DESIGNED and USED
> correctly that is!

it is the final part of that statement that is important

As a generality "Avoid Globals" is not a bad "rule".
there may be some occasions when breaking this rule may be acceptable but 
it requires great experience & detailed knowledge to know when this is 
the right thing to do.

As an analogy music has may general rules that musicians are wise to 
follow.
Some pieces of music that break these rules are great because they have 
broken the rules but most are not. those that are great are great because 
the musician in question understands the reasons for the rules & how 
breaking them will affect the end product, the ones that are bad are 
because the musician does not know enough about music to even know the 
rule exists.





-- 
Immutability, Three Rules of:
(1)  If a tarpaulin can flap, it will.
(2)  If a small boy can get dirty, he will.
(3)  If a teenager can go out, he will.
(3a) If a teenager cant go out, he will. :-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[jongiddy]

On Tuesday, November 12, 2013 2:06:09 AM UTC, Rick Johnson wrote:

> 
> 
> 
>  Justifying Global Variables:
> 
> 
> 
> Globals are justified when they are used to communicate
> 
> information between scopes that otherwise were meant to be
> 
> mutually exclusive. One good example would be package sub-
> 
> modules.
> 

Can you please give an example where having a module provide a global variable 
would work better than any of:
1. providing a module function to change the operation of my module
2. providing a class with a method to change the operation of an instance
3. providing an additional parameter to module functions / instance methods to 
change operation
4. providing additional module functions / instance methods to perform 
different operations
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Tim Chase]

On 2013-11-11 20:46, Rick Johnson wrote:
> Yes, and i agree. But you cannot "hide" everything. There
> will always be a need to share information.

You may not be able to (or want to) hide everything, but sharing
should at least happen over defined protocols (functions/methods).
Otherwise, you wander off into the weeds of hackery and
monkey-patching which makes maintaining the code a lot hairier.

-tkc


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Ricardo Aráoz]

El 12/11/13 01:46, Rick Johnson escribió:
No, Python modules can be poked, prodded, and violated by any pervert 
who can spell the word "import". Attribute values can be reassigned 
and state can be externally manipulated resulting in all types of 
undefined behaviors -- 


Nice!
My code, my responsibility, my business not yours.

that does not sound like an interface to me. So if python modules are 
importable everywhere, and mutable from everywhere, then python 
modules are merely addresses to a collection of global variables? And 
they're only interfaces "superficially"? So that leaves us with 
Python's current implementation of unofficial "global" variables 
implemented as "puesdo- interfaces" by module objects that are victims 
waiting to be violated. Interesting. IF IT WALKS LIKE A GLOBAL DUCK 
AND... 


Nice choice of words, "violated", "victims" Really conductive to a
balanced unprejudiced thought process.

--
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Chris Angelico]

On Tue, Nov 12, 2013 at 3:46 PM, Rick Johnson
 wrote:
> But python modules can't be interfaces because interfaces
> should protect internal data, prevent external forces from
> meddling with internal state (EXCEPT via the rules of a
> predefined "contract"), hide dirty details from the caller,
> and have clearly defined access points.
>
>   BUT PYTHON MODULES DON'T FOLLOW THIS DESIGN PATTERN!
>
> No, Python modules can be poked, prodded, and violated by
> any pervert who can spell the word "import".

And C++ objects can be poked by anyone who can do a pointer cast. And
Java objects by anyone who notices that 'const' checks don't apply to
byte-code. In fact, the only language I can think of that actually
"prevent[s] external forces from meddling with internal state" is
HQ9++, which follows the very best principles of data hiding.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Rick Johnson]

On Monday, November 11, 2013 8:47:09 PM UTC-6, Tim Daneliuk wrote:
> I think this is certainly the use case most people would
> suggest. But I think you may have missed the real reason
> most modern designers object to inter-module globals:  The
> presence of such entities almost always means the code has
> been designed badly.  Whether we're writing pristine OO
> code (cough, cough) or more traditional procedural stuff,
> information hiding is a good thing.

Yes, and i agree. But you cannot "hide" everything. There
will always be a need to share information.

> When and where there is a need for modules (or programs,
> or machines, or "clouds", or interstellar space ...) to
> share information, my view is this is better done via some
> sort of interface/message passing mechanism.

But python modules can't be interfaces because interfaces
should protect internal data, prevent external forces from
meddling with internal state (EXCEPT via the rules of a
predefined "contract"), hide dirty details from the caller,
and have clearly defined access points.

  BUT PYTHON MODULES DON'T FOLLOW THIS DESIGN PATTERN!

No, Python modules can be poked, prodded, and violated by
any pervert who can spell the word "import".

Attribute values can be reassigned and state can be
externally manipulated resulting in all types of undefined
behaviors -- that does not sound like an interface to me.

So if python modules are importable everywhere, and mutable
from everywhere, then python modules are merely addresses to
a collection of global variables? And they're only
interfaces "superficially"?

So that leaves us with Python's current implementation of
unofficial "global" variables implemented as "puesdo-
interfaces" by module objects that are victims waiting to be
violated.

Interesting.

  IF IT WALKS LIKE A GLOBAL DUCK AND...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyMyth: Global variables are evil... WRONG!

[Tim Daneliuk]

On 11/11/2013 08:06 PM, Rick Johnson wrote:

Globals are justified when they are used to communicate
information between scopes that otherwise were meant to be
mutually exclusive.



I think this is certainly the use case most people would suggest.

But I think you may have missed the real reason most modern
designers object to inter-module globals:  The presence of
such entities almost always means the code has been designed
badly.  Whether we're writing pristine OO code (cough, cough)
or more traditional procedural stuff, information hiding
is a good thing.  When and where there is a need for modules
(or programs, or machines, or "clouds", or interstellar space ...)
to share information, my view is this is better done via some sort
of interface/message passing mechanism.  The more "things" that have
to be shared across modules/programs/machines/clouds/space ... the more
*brittle* the end system becomes.

This problem is broader than just variables, BTW.  It exists anytime you
share *anything* across many computational components, especially in highly
parallel and/or distributed systems.  For example, RPCs tend to be lousy
at building high scale distributed system because they usually have
a call-and-wait semantic which will fail if the caller never responds.
In this case the system is sharing the semantics of *time*.  As a general
matter, exactly-once asynchronous messaging tends to be a better implementation
model here.

Just my 2 cents worth.  Interesting read.  Thanks for taking the time
--

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

--
https://mail.python.org/mailman/listinfo/python-list

PyMyth: Global variables are evil... WRONG!

[Rick Johnson]

PyMyth: Global variables are evil... WRONG!


 Python's Global Hysteria:

How many times have your heard or read the phrase: "Global
variables are evil"? Well if you've been a member of the
Python community, I'll bet you've heard or read it more than
most other community members.

In this thread, i want to get to the bottom of this whole
"global-phobia" thing once and for all, and hopefully help
you folks understand that globals are not all that bad --
when DESIGNED and USED correctly that is!


 The denial of the 99%:

Python has globals, but we just can't admit it!

The creators thought they would prevent the little
"PyPeople" from hurting themselves by "handicapping" our
globals in the form of "module level" globals.

But even the "module level" globals can be accessed
"globally" if the module they are contained in is imported
everywhere.

import glomod
glomod.var # Access
global.var = newValue

Which leads me to the conclusion that the designers were
either naive or underestimated the chutzpah of this fine
community.


 The Power of the 1%:

Most of this "fear of globals" can be traced back to a
minority of naive coders who used globals haphazardly and
were hurt by them, and now we ALL have to suffer
because future idiots need to be protected from themselves!


Too many times I've seen idiotic uses for globals.

One more atrocious example was "dialog return values" stored
as globals so the "dumb coder" could eaisly restore the
previous state of the dialog values between successive
calls.

Obviously the best solution would be for the dialog object
ITSELF to store (and restore) the values when necessary, but
alas, here i am again expecting people to create interfaces
that are consistent and logical. *rolls-eyes*

Of course we can only blame the dialog designer and not the
caller for this design flaw, but the caller still has no
excuse for globally storaging these values.

If the caller cannot repair the mistake by extending the
dialog object himself, then he can store the values within
the current module or class level scope. There is no excuse
for elevating this information to global scope.

However, there ARE justified uses of global variables!


 Justifying Global Variables:

Globals are justified when they are used to communicate
information between scopes that otherwise were meant to be
mutually exclusive. One good example would be package sub-
modules.

Now. Some might believe that the purity of namespaces
becomes tainted if they can be violently penetrated by
global variables. But again, they are falling back on gut
reactions fostered from years of brain washing. Yes, globals
can be bad (if misused), but for the most part they are
crucial to transferring information CLEANLY between isolated
namespaces

But even globals themselves are not good enough UNLESS we
engineer a "global hierarchy"!


 From Flat to Nested == From Tricked to Bested:

One of the shortcomings of the current implementation of
global variables is their inherent "flat" access nature.
There is no hierarchy of globals, and once all the good
names are taken, your screwed!

 "But Rick, even when we use globals, we don't need that many"

Only if you consider the single package that represents your
program, but what about the thousands of support libraries
with millions of lines of code that work in the background
to make your measly few thousand lines of code work?  What
about all the globals that they have injected?

 "Never thought of that really"

Throwing out global names UNADORNED is folly. Could you
imagine telephone numbers without area codes?

 Hmm: Am i calling "Jim" in Beverly Hills California???

   california.beverlyhills.jim

 or "Jim" in "Spokane Washington"???

   washington.spokane.jim

You see, you need to QUALIFY these names not only to make
then unique, but also so the caller will understand who he
is calling.

Same goes for globals.
-- 
https://mail.python.org/mailman/listinfo/python-list

Global variables in a C extension for Python

[Lorenzo Di Gregorio]

Hello,

I've written a C extension for Python which works so far, but now I've
stumbled onto a simple problem for which I just can't find any example
on the web, so here I am crying for help ;-)

I'll trying to reduce the problem to a minimal example.  Let's say I
need to call from Python functions of a C program like:

static int counter = 0;
void do_something(...) {
... counter++; ...
}
void do_something_else(...) {
... counter++; ...
}

So they access a common global variable.  I've written the wrappers
for the functions, but I'd like to place "counter" in the module's
space and have wrappers accessing it like self->counter.  I do not
need to make "counter" visible to Python, I just need the global
static variable available for C.

I've got somehow a clue of how this should work, but not much more
than a clue, and I'd appreciate to see a simple example.

Best Regards,
Lorenzo
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: executing a function with feeding its global variables

[Jean-Daniel]

On Sat, Feb 12, 2011 at 7:25 PM, Peter Otten <__pete...@web.de> wrote:
> Jean-Daniel wrote:
>
>> Hello,
>>
>> I am writing a small framework where the user which writes a function
>> can expect some global variable to be set in the function namespace.
>>
>> The user has to write a function like this:
>> """
>> # function.py
>> from framework import, command, run
>>
>> @command
>> def myfunc():
>>     print HOST
>>
>> if __name__=="__main__":
>>     run()
>> """
>>
>> command() registers the function, and run() evaluates or execute the
>> function within an environment or a namespace where HOST has been
>> automagically set.
>>
>> Question: how can write run in a way that when using run() in a
>> script, the decorated function will be run with the special names made
>> available?
>>
>> Here is the code for this, which does not work as intended because the
>> 'HOST' can not be found when evaluating the decorated function
>>
>> """
>> # framework.py
>> HOST = '192.168.0.1'
>> PORT = 12345
>>
>> commands = []
>>
>> def command(f):
>>     commands.append(f)
>>     return f
>>
>> def run():
>>     for f in commands:
>>         assert globals()['HOST']
>>         exec 'f()' in globals(),locals()
>>
>> if __name__=='__main__':
>>
>>     @command
>>     def info():
>>         print HOST,PORT
>>
>>     run()
>> """
>>
>> Note that the assert makes sure the HOST variable is indeed present in
>> the globals when running the function. When running function.py, I get
>> an NameError exception. When I put the func function in the framework
>> module and execute framework.py as a script, this works fine, the
>> global HOST is available in the func namespace which gets printed. I
>> tried many combinations of eval() or exec as well as many combinations
>> for the globals() and locals() mapping fed to eval/exec without
>> success.
>
> Every module has its own global namespace, and a function is looking for
> global variables in the namespace it is defined in, not the one where the
> function is called from. A function defined in Python carries its global
> namespace with it as the __globals__ attribute (func_globals in older Python
> versions).
>
> def run():
>    for f in commands:
>        f.__globals__.update(HOST=HOST, PORT=PORT)
>        f()
>
> Note that every function in the function's module will see the extra
> variables.

Cool, thanks.

I read here: http://docs.python.org/reference/datamodel.html about the
func_globals and how it is a read only attribute. I incorrectly
thought that this dictionary was read only because the reference was
read only.


>
> Peter
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: executing a function with feeding its global variables

[Peter Otten]

Jean-Daniel wrote:

> Hello,
> 
> I am writing a small framework where the user which writes a function
> can expect some global variable to be set in the function namespace.
> 
> The user has to write a function like this:
> """
> # function.py
> from framework import, command, run
> 
> @command
> def myfunc():
> print HOST
> 
> if __name__=="__main__":
> run()
> """
> 
> command() registers the function, and run() evaluates or execute the
> function within an environment or a namespace where HOST has been
> automagically set.
> 
> Question: how can write run in a way that when using run() in a
> script, the decorated function will be run with the special names made
> available?
> 
> Here is the code for this, which does not work as intended because the
> 'HOST' can not be found when evaluating the decorated function
> 
> """
> # framework.py
> HOST = '192.168.0.1'
> PORT = 12345
> 
> commands = []
> 
> def command(f):
> commands.append(f)
> return f
> 
> def run():
> for f in commands:
> assert globals()['HOST']
> exec 'f()' in globals(),locals()
> 
> if __name__=='__main__':
> 
> @command
> def info():
> print HOST,PORT
> 
> run()
> """
> 
> Note that the assert makes sure the HOST variable is indeed present in
> the globals when running the function. When running function.py, I get
> an NameError exception. When I put the func function in the framework
> module and execute framework.py as a script, this works fine, the
> global HOST is available in the func namespace which gets printed. I
> tried many combinations of eval() or exec as well as many combinations
> for the globals() and locals() mapping fed to eval/exec without
> success.

Every module has its own global namespace, and a function is looking for 
global variables in the namespace it is defined in, not the one where the 
function is called from. A function defined in Python carries its global 
namespace with it as the __globals__ attribute (func_globals in older Python 
versions).

def run():
for f in commands:
f.__globals__.update(HOST=HOST, PORT=PORT)
f()

Note that every function in the function's module will see the extra 
variables.

Peter
-- 
http://mail.python.org/mailman/listinfo/python-list

executing a function with feeding its global variables

[Jean-Daniel]

Hello,

I am writing a small framework where the user which writes a function
can expect some global variable to be set in the function namespace.

The user has to write a function like this:
"""
# function.py
from framework import, command, run

@command
def myfunc():
print HOST

if __name__=="__main__":
run()
"""

command() registers the function, and run() evaluates or execute the
function within an environment or a namespace where HOST has been
automagically set.

Question: how can write run in a way that when using run() in a
script, the decorated function will be run with the special names made
available?

Here is the code for this, which does not work as intended because the
'HOST' can not be found when evaluating the decorated function

"""
# framework.py
HOST = '192.168.0.1'
PORT = 12345

commands = []

def command(f):
commands.append(f)
return f

def run():
for f in commands:
assert globals()['HOST']
exec 'f()' in globals(),locals()

if __name__=='__main__':

@command
def info():
print HOST,PORT

run()
"""

Note that the assert makes sure the HOST variable is indeed present in
the globals when running the function. When running function.py, I get
an NameError exception. When I put the func function in the framework
module and execute framework.py as a script, this works fine, the
global HOST is available in the func namespace which gets printed. I
tried many combinations of eval() or exec as well as many combinations
for the globals() and locals() mapping fed to eval/exec without
success.


Thank you for your help
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Global variables problem

[Jean-Michel Pichavant]

Navkirat Singh wrote:


On 04-Aug-2010, at 9:46 AM, Daniel da Silva wrote:

Please post approximate code that actually works and displays the 
problem.


On Tue, Aug 3, 2010 at 9:00 PM, Navkirat Singh > wrote:


Hey guys,

I am using a multiprocessing program, where the new process is
supposed to change a variable in the main class that it branches
out from. This is somehow not working, following is an
approximate code. Would really appreciate any insight into this
matter:


var = {}

class Something():

   def set_var(self):
   global var
   var = somevalue

   def get_var(self):
   return var

   def newprocess(self):
   self.set_var()

   def do_multiprocessing(self):
   while true:
   self.get_var()
   new_process = process(target=newprocess)
   new_process.start()


I am really confused here !

Any help would be awesome : )

Regards,
Nav

--
http://mail.python.org/mailman/listinfo/python-list




This is a working code, streamlined, but it is where the problem is:

from multiprocessing import * 


dicts = 0
print('global ', dicts)

class WebServer():
def set_sessionInfo(self):
global dicts
dicts = dicts + 1
def get_sessionInfo(self):
return dicts

def handle_connection(self):
self.set_sessionInfo()
def serve_forever(self):
for x in range(10):
p = Process(target=self.handle_connection)
p.start()
print(self.get_sessionInfo())
ws = WebServer()
ws.serve_forever()
print(dicts)




"As mentioned above, when doing concurrent programming it is usually 
best to avoid using shared state as far as possible. This is 
particularly true when using multiple processes.


However, if you really do need to use some shared data then 
multiprocessing provides a couple of ways of doing so."


source :

http://docs.python.org/library/multiprocessing.html


Read it, everything is explained with examples, including how to 
properly solve your problem.
"When using multiple processes, one generally uses message passing for 
communication between processes and avoids having to use any 
synchronization primitives like locks."


JM
--
http://mail.python.org/mailman/listinfo/python-list

Re: Global variables problem

[Matteo Landi]

Usually, modify global variables in a multi-thread/multi-process
scenario is not the right to operate: you better re-implement your
solution in a way that the shared resource is either protected with
synchronized objects or accessed by a single thread/process (and in
this case,  it won't be a shared resource anymore).

Think about the the needs of the shared resources: in this extremely
simple example, you can see that the increment of the session number
could be done by the server before spawning the child, but obviously
this is not a real scenario.

If you can't give up with shared resources, I recommend you to create
a synchronized object owned by the server but shared with the children
(take a look at the args keywords of the Process constructor).

Regards.

On Wed, Aug 4, 2010 at 9:47 AM, Navkirat Singh  wrote:
>  : (
> False alarm, the earlier solution breaks multiprocessing. Whats happening
> here is the child needs to change a variable in the parent process, So I
> think I am looking at shared memory (maybe). Any suggestions?
> Regards,
> Nav
>
>
> On 04-Aug-2010, at 12:41 PM, Navkirat Singh wrote:
>
> Thanks a lot guys !!
> I solved the problem:
> In the lines:
>>>
>>> new_process = process(target=newprocess)
>>>                        new_process.start()
>
> The target=newprocess is pointing towards a variable, instead of a function.
> So, appending a () will make it goto that function, thereby changing the
> global variable : )
> Thanks,
> Nav
>
> On 04-Aug-2010, at 11:42 AM, Daniel da Silva wrote:
>
> Your problem lies somewhere in the use of the Process class, not with global
> variables.
>
> If you replace your "p = ..." and "p.start()" lines with a direct call to
> self.handle_connection(), your code works as expected. I don't know much
> about the multiprocessing module, so I can't really comment on what you're
> doing wrong, but I hope this points you in the right direction.
>
> Sorry I couldn't be of more help,
>
> Daniel
>
>
> On Tue, Aug 3, 2010 at 9:48 PM, Navkirat Singh  wrote:
>>
>> On 04-Aug-2010, at 9:46 AM, Daniel da Silva wrote:
>>
>> Please post approximate code that actually works and displays the problem.
>>
>> On Tue, Aug 3, 2010 at 9:00 PM, Navkirat Singh 
>> wrote:
>>>
>>> Hey guys,
>>>
>>> I am using a multiprocessing program, where the new process is supposed
>>> to change a variable in the main class that it branches out from. This is
>>> somehow not working, following is an approximate code. Would really
>>> appreciate any insight into this matter:
>>>
>>>
>>> var = {}
>>>
>>> class Something():
>>>
>>>        def set_var(self):
>>>                global var
>>>                var = somevalue
>>>
>>>        def get_var(self):
>>>                return var
>>>
>>>        def newprocess(self):
>>>                self.set_var()
>>>
>>>        def do_multiprocessing(self):
>>>                while true:
>>>                        self.get_var()
>>>                        new_process = process(target=newprocess)
>>>                        new_process.start()
>>>
>>>
>>> I am really confused here !
>>>
>>> Any help would be awesome : )
>>>
>>> Regards,
>>> Nav
>>>
>>> --
>>> http://mail.python.org/mailman/listinfo/python-list
>>
>>
>> This is a working code, streamlined, but it is where the problem is:
>> from multiprocessing import *
>> dicts = 0
>> print('global ', dicts)
>> class WebServer():
>> def set_sessionInfo(self):
>> global dicts
>> dicts = dicts + 1
>> def get_sessionInfo(self):
>> return dicts
>> def handle_connection(self):
>> self.set_sessionInfo()
>> def serve_forever(self):
>> for x in range(10):
>> p = Process(target=self.handle_connection)
>> p.start()
>> print(self.get_sessionInfo())
>> ws = WebServer()
>> ws.serve_forever()
>> print(dicts)
>>
>
>
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
>



-- 
Matteo Landi
http://www.matteolandi.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Global variables problem

[Navkirat Singh]

 : ( 

False alarm, the earlier solution breaks multiprocessing. Whats happening here 
is the child needs to change a variable in the parent process, So I think I am 
looking at shared memory (maybe). Any suggestions?

Regards,
Nav



On 04-Aug-2010, at 12:41 PM, Navkirat Singh wrote:

> Thanks a lot guys !!
> 
> I solved the problem:
> 
> In the lines:
> 
>>> new_process = process(target=newprocess)
>>>new_process.start()
> 
> 
> 
> The target=newprocess is pointing towards a variable, instead of a function. 
> So, appending a () will make it goto that function, thereby changing the 
> global variable : )
> 
> Thanks,
> Nav
> 
> 
> On 04-Aug-2010, at 11:42 AM, Daniel da Silva wrote:
> 
>> Your problem lies somewhere in the use of the Process class, not with global 
>> variables.
>> 
>> If you replace your "p = ..." and "p.start()" lines with a direct call to 
>> self.handle_connection(), your code works as expected. I don't know much 
>> about the multiprocessing module, so I can't really comment on what you're 
>> doing wrong, but I hope this points you in the right direction.
>> 
>> Sorry I couldn't be of more help,
>> 
>> Daniel
>> 
>> 
>> On Tue, Aug 3, 2010 at 9:48 PM, Navkirat Singh  wrote:
>> 
>> On 04-Aug-2010, at 9:46 AM, Daniel da Silva wrote:
>> 
>>> Please post approximate code that actually works and displays the problem. 
>>> 
>>> On Tue, Aug 3, 2010 at 9:00 PM, Navkirat Singh  wrote:
>>> Hey guys,
>>> 
>>> I am using a multiprocessing program, where the new process is supposed to 
>>> change a variable in the main class that it branches out from. This is 
>>> somehow not working, following is an approximate code. Would really 
>>> appreciate any insight into this matter:
>>> 
>>> 
>>> var = {}
>>> 
>>> class Something():
>>> 
>>>def set_var(self):
>>>global var
>>>var = somevalue
>>> 
>>>def get_var(self):
>>>return var
>>> 
>>>def newprocess(self):
>>>self.set_var()
>>> 
>>>def do_multiprocessing(self):
>>>while true:
>>>self.get_var()
>>>new_process = process(target=newprocess)
>>>new_process.start()
>>> 
>>> 
>>> I am really confused here !
>>> 
>>> Any help would be awesome : )
>>> 
>>> Regards,
>>> Nav
>>> 
>>> --
>>> http://mail.python.org/mailman/listinfo/python-list
>>> 
>> 
>> This is a working code, streamlined, but it is where the problem is:
>> 
>> from multiprocessing import * 
>> 
>> dicts = 0
>> print('global ', dicts)
>> 
>> class WebServer():
>>  
>>  def set_sessionInfo(self):
>>  global dicts
>>  dicts = dicts + 1
>>  
>>  def get_sessionInfo(self):
>>  return dicts
>> 
>>  def handle_connection(self):
>>  self.set_sessionInfo()
>>  
>>  def serve_forever(self):
>>  for x in range(10):
>>  p = Process(target=self.handle_connection)
>>  p.start()
>>  print(self.get_sessionInfo())
>>  
>> ws = WebServer()
>> ws.serve_forever()
>> print(dicts)
>> 
>> 
>> 
> 

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Global variables problem

[Navkirat Singh]

Thanks a lot guys !!

I solved the problem:

In the lines:

>> new_process = process(target=newprocess)
>>new_process.start()



The target=newprocess is pointing towards a variable, instead of a function. 
So, appending a () will make it goto that function, thereby changing the global 
variable : )

Thanks,
Nav


On 04-Aug-2010, at 11:42 AM, Daniel da Silva wrote:

> Your problem lies somewhere in the use of the Process class, not with global 
> variables.
> 
> If you replace your "p = ..." and "p.start()" lines with a direct call to 
> self.handle_connection(), your code works as expected. I don't know much 
> about the multiprocessing module, so I can't really comment on what you're 
> doing wrong, but I hope this points you in the right direction.
> 
> Sorry I couldn't be of more help,
> 
> Daniel
> 
> 
> On Tue, Aug 3, 2010 at 9:48 PM, Navkirat Singh  wrote:
> 
> On 04-Aug-2010, at 9:46 AM, Daniel da Silva wrote:
> 
>> Please post approximate code that actually works and displays the problem. 
>> 
>> On Tue, Aug 3, 2010 at 9:00 PM, Navkirat Singh  wrote:
>> Hey guys,
>> 
>> I am using a multiprocessing program, where the new process is supposed to 
>> change a variable in the main class that it branches out from. This is 
>> somehow not working, following is an approximate code. Would really 
>> appreciate any insight into this matter:
>> 
>> 
>> var = {}
>> 
>> class Something():
>> 
>>def set_var(self):
>>global var
>>var = somevalue
>> 
>>def get_var(self):
>>return var
>> 
>>def newprocess(self):
>>self.set_var()
>> 
>>def do_multiprocessing(self):
>>while true:
>>self.get_var()
>>new_process = process(target=newprocess)
>>new_process.start()
>> 
>> 
>> I am really confused here !
>> 
>> Any help would be awesome : )
>> 
>> Regards,
>> Nav
>> 
>> --
>> http://mail.python.org/mailman/listinfo/python-list
>> 
> 
> This is a working code, streamlined, but it is where the problem is:
> 
> from multiprocessing import * 
> 
> dicts = 0
> print('global ', dicts)
> 
> class WebServer():
>   
>   def set_sessionInfo(self):
>   global dicts
>   dicts = dicts + 1
>   
>   def get_sessionInfo(self):
>   return dicts
> 
>   def handle_connection(self):
>   self.set_sessionInfo()
>   
>   def serve_forever(self):
>   for x in range(10):
>   p = Process(target=self.handle_connection)
>   p.start()
>   print(self.get_sessionInfo())
>   
> ws = WebServer()
> ws.serve_forever()
> print(dicts)
> 
> 
> 

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Global variables problem

[Daniel da Silva]

Your problem lies somewhere in the use of the Process class, not with global
variables.

If you replace your "p = ..." and "p.start()" lines with a direct call to
self.handle_connection(), your code works as expected. I don't know much
about the multiprocessing module, so I can't really comment on what you're
doing wrong, but I hope this points you in the right direction.

Sorry I couldn't be of more help,

Daniel


On Tue, Aug 3, 2010 at 9:48 PM, Navkirat Singh  wrote:

>
> On 04-Aug-2010, at 9:46 AM, Daniel da Silva wrote:
>
> Please post approximate code that actually works and displays the problem.
>
> On Tue, Aug 3, 2010 at 9:00 PM, Navkirat Singh wrote:
>
>> Hey guys,
>>
>> I am using a multiprocessing program, where the new process is supposed to
>> change a variable in the main class that it branches out from. This is
>> somehow not working, following is an approximate code. Would really
>> appreciate any insight into this matter:
>>
>>
>> var = {}
>>
>> class Something():
>>
>>def set_var(self):
>>global var
>>var = somevalue
>>
>>def get_var(self):
>>return var
>>
>>def newprocess(self):
>>self.set_var()
>>
>>def do_multiprocessing(self):
>>while true:
>>self.get_var()
>>new_process = process(target=newprocess)
>>new_process.start()
>>
>>
>> I am really confused here !
>>
>> Any help would be awesome : )
>>
>> Regards,
>> Nav
>>
>> --
>> http://mail.python.org/mailman/listinfo/python-list
>>
>
>
> This is a working code, streamlined, but it is where the problem is:
>
> from multiprocessing import *
>
> dicts = 0
> print('global ', dicts)
>
> class WebServer():
>  def set_sessionInfo(self):
> global dicts
> dicts = dicts + 1
>  def get_sessionInfo(self):
> return dicts
>
> def handle_connection(self):
> self.set_sessionInfo()
>  def serve_forever(self):
> for x in range(10):
> p = Process(target=self.handle_connection)
> p.start()
> print(self.get_sessionInfo())
> ws = WebServer()
> ws.serve_forever()
> print(dicts)
>
>
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Global variables problem

[Navkirat Singh]

On 04-Aug-2010, at 9:46 AM, Daniel da Silva wrote:

> Please post approximate code that actually works and displays the problem. 
> 
> On Tue, Aug 3, 2010 at 9:00 PM, Navkirat Singh  wrote:
> Hey guys,
> 
> I am using a multiprocessing program, where the new process is supposed to 
> change a variable in the main class that it branches out from. This is 
> somehow not working, following is an approximate code. Would really 
> appreciate any insight into this matter:
> 
> 
> var = {}
> 
> class Something():
> 
>def set_var(self):
>global var
>var = somevalue
> 
>def get_var(self):
>return var
> 
>def newprocess(self):
>self.set_var()
> 
>def do_multiprocessing(self):
>while true:
>self.get_var()
>new_process = process(target=newprocess)
>new_process.start()
> 
> 
> I am really confused here !
> 
> Any help would be awesome : )
> 
> Regards,
> Nav
> 
> --
> http://mail.python.org/mailman/listinfo/python-list
> 

This is a working code, streamlined, but it is where the problem is:

from multiprocessing import * 

dicts = 0
print('global ', dicts)

class WebServer():

def set_sessionInfo(self):
global dicts
dicts = dicts + 1

def get_sessionInfo(self):
return dicts

def handle_connection(self):
self.set_sessionInfo()

def serve_forever(self):
for x in range(10):
p = Process(target=self.handle_connection)
p.start()
print(self.get_sessionInfo())

ws = WebServer()
ws.serve_forever()
print(dicts)


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Global variables problem

[Daniel da Silva]

Please post approximate code that actually works and displays the problem.

On Tue, Aug 3, 2010 at 9:00 PM, Navkirat Singh  wrote:

> Hey guys,
>
> I am using a multiprocessing program, where the new process is supposed to
> change a variable in the main class that it branches out from. This is
> somehow not working, following is an approximate code. Would really
> appreciate any insight into this matter:
>
>
> var = {}
>
> class Something():
>
>def set_var(self):
>global var
>var = somevalue
>
>def get_var(self):
>return var
>
>def newprocess(self):
>self.set_var()
>
>def do_multiprocessing(self):
>while true:
>self.get_var()
>new_process = process(target=newprocess)
>new_process.start()
>
>
> I am really confused here !
>
> Any help would be awesome : )
>
> Regards,
> Nav
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Global variables problem

[Navkirat Singh]

Hey guys,

I am using a multiprocessing program, where the new process is supposed to 
change a variable in the main class that it branches out from. This is somehow 
not working, following is an approximate code. Would really appreciate any 
insight into this matter:


var = {}

class Something():

def set_var(self):
global var
var = somevalue

def get_var(self):
return var

def newprocess(self):
self.set_var()

def do_multiprocessing(self):
while true:
self.get_var()
new_process = process(target=newprocess)
new_process.start()


I am really confused here !

Any help would be awesome : )

Regards,
Nav 

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Global variables for python applications

[TomF]

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

[Steven D'Aprano]

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

[TomF]

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


--
http://mail.python.org/mailman/listinfo/python-list

Re: Global variables for python applications

[Duncan Booth]

Steven D'Aprano  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

[Steven D'Aprano]

On Mon, 17 May 2010 23:54:38 +0100, Rhodri James wrote:

> On Mon, 17 May 2010 05:29:20 +0100, Steven D'Aprano
>  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

[Giampaolo Rodolà]

2010/5/16 Chris Rebert :
> On Sun, May 16, 2010 at 10:50 AM, AON LAZIO  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

[Rhodri James]

On Mon, 17 May 2010 05:29:20 +0100, Steven D'Aprano  
 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

[Steven D'Aprano]

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

[Gregory Ewing]

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

[James Mills]

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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Global variables for python applications

[Steven D'Aprano]

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

[Steven D'Aprano]

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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Global variables for python applications

[James Mills]

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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Global variables for python applications

[John Nagle]

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 in imported modules

[vsoler]

On 17 mayo, 00:52, Patrick Maupin  wrote:
> On May 16, 5:38 pm, James Mills  wrote:
>
> > On Mon, May 17, 2010 at 8:26 AM, vsoler  wrote:
> > > However, can I be 100% sure that,no matter how I access variable
> > > 'x' (with config.x or mod.config.x) it is always the same 'x'. I mean
> > > that either reference of 'x' points to the same id(memory position)?
>
> > Yes it does unless you re-assign it.
>
> > --James
>
> To expand a bit on what James is saying:
>
> If, for example, inside your main module, you got tired of typing
> "mod.config.x" everywhere you were using it, and decided that you
> could make a local reference to the same variable:
>
> x = mod.config.x
>
> Now, whenever you use just plain x inside the main module, you are
> also referencing the exact same object, *until* some other function
> decides to do:
>
> mod.config.x = y
>
> At this point in time, the 'x' inside main references the object that
> mod.config.x originally referenced, but mod.config.x now references a
> different object.
>
> Unlike C, for example, where the assignment operator physically places
> an item into a specific memory location (either fixed globally or
> within a stack frame), the assignment operator in python simply stores
> a key/value pair into a namespace dictionary.  So whenever you
> retrieve a value from the dictionary using that key, you will get the
> value that was last associated with that key.
>
> So, 'mod.config.x' will first retrieve the object associated with the
> key 'mod' from the main module's namespace dictionary, then will
> retrieve the object associated with the key 'config' from that
> module's namespace dictionary, then will retrieve the object
> associated with the key 'x' from that module's namespace dictionary.
> Unless you later modify any of those key/value pairs, subsequent
> retrieval will always result in the same final value.
>
> Regards,
> Pat

Really interesting, it helps a lot.

Thank you
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: global variables in imported modules

[Patrick Maupin]

On May 16, 5:38 pm, James Mills  wrote:
> On Mon, May 17, 2010 at 8:26 AM, vsoler  wrote:
> > However, can I be 100% sure that,no matter how I access variable
> > 'x' (with config.x or mod.config.x) it is always the same 'x'. I mean
> > that either reference of 'x' points to the same id(memory position)?
>
> Yes it does unless you re-assign it.
>
> --James


To expand a bit on what James is saying:

If, for example, inside your main module, you got tired of typing
"mod.config.x" everywhere you were using it, and decided that you
could make a local reference to the same variable:

x = mod.config.x

Now, whenever you use just plain x inside the main module, you are
also referencing the exact same object, *until* some other function
decides to do:

mod.config.x = y

At this point in time, the 'x' inside main references the object that
mod.config.x originally referenced, but mod.config.x now references a
different object.

Unlike C, for example, where the assignment operator physically places
an item into a specific memory location (either fixed globally or
within a stack frame), the assignment operator in python simply stores
a key/value pair into a namespace dictionary.  So whenever you
retrieve a value from the dictionary using that key, you will get the
value that was last associated with that key.

So, 'mod.config.x' will first retrieve the object associated with the
key 'mod' from the main module's namespace dictionary, then will
retrieve the object associated with the key 'config' from that
module's namespace dictionary, then will retrieve the object
associated with the key 'x' from that module's namespace dictionary.
Unless you later modify any of those key/value pairs, subsequent
retrieval will always result in the same final value.

Regards,
Pat
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: global variables in imported modules

[vsoler]

On 17 mayo, 00:38, James Mills  wrote:
> On Mon, May 17, 2010 at 8:26 AM, vsoler  wrote:
> > However, can I be 100% sure that,no matter how I access variable
> > 'x' (with config.x or mod.config.x) it is always the same 'x'. I mean
> > that either reference of 'x' points to the same id(memory position)?
>
> Yes it does unless you re-assign it.
>
> --James

Understood, thank you very much

Vicente Soler
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: global variables in imported modules

[James Mills]

On Mon, May 17, 2010 at 8:26 AM, vsoler  wrote:
> However, can I be 100% sure that,no matter how I access variable
> 'x' (with config.x or mod.config.x) it is always the same 'x'. I mean
> that either reference of 'x' points to the same id(memory position)?

Yes it does unless you re-assign it.

--James
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: global variables in imported modules

[vsoler]

On 17 mayo, 00:05, Patrick Maupin  wrote:
> On May 16, 4:42 pm, vsoler  wrote:
>
>
>
> > Taken fromwww.python.org, FAQ 2.3 How do I share global variables
> > across modules?
>
> > config.py:
>
> > x = 0   # Default value of the 'x' configuration setting
>
> > mod.py:
>
> > import config
> > config.x = 1
>
> > main.py:
>
> > import config       # try removing it
> > import mod
> > print config.x
>
> > The example, such as shown in the website, works perfectly well.
> > However, I don't fully understand why I have to import config in
> > main.py, since it has already been imported by mod.py.
>
> > As the website explains, there is only one module namespace for each
> > module, and mod.py has aleady created the config namespace by
> > importing it. Why should I import it again in main.py if that
> > namespace already exists?
>
> > If I remove ->   import config       # try removing it     in main.py,
> > the application does not run
>
> > What am I missing?
>
> What you are missing is that the interpreter has to look *inside* a
> namespace in order to actually find the object associated with a
> name.  As you found out, there is a namespace per module.  So
> main.py's namespace is where the code in main.py will search for
> variables.  If 'mod' imports config, then the 'mod' module's namespace
> is updated with 'config' -> the config module.  But the act of 'mod'
> importing 'config' will not alter the namespace of 'main' at all.  So
> if you want to access variable 'x' inside 'config' from main you can
> either import config directly into main and access it as config.x, or
> you can import config into mod and import mod into main and access it
> as mod.config.x.
>
> Regards,
> Pat

Thank you Pat, it's very clear.

However, can I be 100% sure that,no matter how I access variable
'x' (with config.x or mod.config.x) it is always the same 'x'. I mean
that either reference of 'x' points to the same id(memory position)?

Thank you
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: global variables in imported modules

[Rhodri James]

On Sun, 16 May 2010 22:42:40 +0100, vsoler  wrote:


Taken from www.python.org, FAQ 2.3 How do I share global variables
across modules?

config.py:

x = 0   # Default value of the 'x' configuration setting


mod.py:

import config
config.x = 1


main.py:

import config   # try removing it
import mod
print config.x

The example, such as shown in the website, works perfectly well.
However, I don't fully understand why I have to import config in
main.py, since it has already been imported by mod.py.


Globals are only global to a module.  As you can see above, they
don't magically appear in the namespace of the module you import
them into (not unless you do something careless like "from config
import *", at which point you deserve all the confusion you're
going to get).  In both mod.py and main.py you get at the global
x through its module: config.x

Now as you say, main.py imports mod.  In exactly the same way as
mod imports config.  *Exactly*.  We get at the contents of mod
(the things in its namespace) in the same way: mod.thing.  When
mod imports config it imports it into its own namespace only;
there is no magic that makes it appear in the namespace of anything
importing mod any more than happens for anything else.

If you want to access config in main.py without importing it
directly because you know that (in this case) mod has already
imported it, you have to access it through the module that did
the importing.  Instead of "config.x", in main it would be
"mod.config.x".

--
Rhodri James *-* Wildebeeste Herder to the Masses
--
http://mail.python.org/mailman/listinfo/python-list

Re: global variables in imported modules

[Patrick Maupin]

On May 16, 4:42 pm, vsoler  wrote:
> Taken fromwww.python.org, FAQ 2.3 How do I share global variables
> across modules?
>
> config.py:
>
> x = 0   # Default value of the 'x' configuration setting
>
> mod.py:
>
> import config
> config.x = 1
>
> main.py:
>
> import config       # try removing it
> import mod
> print config.x
>
> The example, such as shown in the website, works perfectly well.
> However, I don't fully understand why I have to import config in
> main.py, since it has already been imported by mod.py.
>
> As the website explains, there is only one module namespace for each
> module, and mod.py has aleady created the config namespace by
> importing it. Why should I import it again in main.py if that
> namespace already exists?
>
> If I remove ->   import config       # try removing it     in main.py,
> the application does not run
>
> What am I missing?

What you are missing is that the interpreter has to look *inside* a
namespace in order to actually find the object associated with a
name.  As you found out, there is a namespace per module.  So
main.py's namespace is where the code in main.py will search for
variables.  If 'mod' imports config, then the 'mod' module's namespace
is updated with 'config' -> the config module.  But the act of 'mod'
importing 'config' will not alter the namespace of 'main' at all.  So
if you want to access variable 'x' inside 'config' from main you can
either import config directly into main and access it as config.x, or
you can import config into mod and import mod into main and access it
as mod.config.x.

Regards,
Pat
-- 
http://mail.python.org/mailman/listinfo/python-list

global variables in imported modules

[vsoler]

Taken from www.python.org, FAQ 2.3 How do I share global variables
across modules?

config.py:

x = 0   # Default value of the 'x' configuration setting


mod.py:

import config
config.x = 1


main.py:

import config   # try removing it
import mod
print config.x

The example, such as shown in the website, works perfectly well.
However, I don't fully understand why I have to import config in
main.py, since it has already been imported by mod.py.

As the website explains, there is only one module namespace for each
module, and mod.py has aleady created the config namespace by
importing it. Why should I import it again in main.py if that
namespace already exists?

If I remove ->   import config   # try removing it in main.py,
the application does not run

What am I missing?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Global variables for python applications

[christian schulze]

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

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
-- 
http://mail.python.org/mailman/listinfo/python-list