wxPython having trouble with frame objects

[Dave Angel]

Soumen banerjee wrote:
> Hello,
> The code works almost perfectly. I was able to correct some small
> things, and get it to work brilliantly. I would like to thank you for
> your dedicated help. My understanding of the matter here has improved
> by a lot due to your kind help. I will further work on your
> suggestions. By the way why should the general rule in 5 apply with
> respect to private and global variables?
> Regards
> Soumen
>
> On Fri, May 1, 2009 at 7:10 PM, Dave Angel <davea at dejaviewphoto.com> wrote:
>   
>> Soumen banerjee wrote:
>>     
> <snip>
You accidentally top-posted, so your response is at the beginning, 
rather than in sequence. You also forgot to CC the PythonList, so nobody 
else will see it.

One typo I thought of after hitting "send" was I omitted the 'self' 
parameter when calling the parent __init__() methods.

function variables are preferred over globals for several reasons.  One 
is that there's less likelihood of accidentally getting the wrong 
value.  If two different functions use the same name for something, 
there's no confusion unless one of them decides to make it global.  This 
is referred to as namespace pollution.  Generally, the fewer names that 
are visible at any moment, the better.  Much better to get an error than 
use the worng one.  Other namespace cases is my preference of simple 
import over   from xxx import yyy.  It means that a reference to 
something from the import takes more typing, but is clearer to the reader.

Second problem with globals is that if you write a successful program to 
do something once, it very well might not work if you just repeat it,  
because you might forget to re-initialize the globals.  If this were the 
only problem, I might solve it by making a "init_globals()" function 
that uses the global keyword to export the names it's initializing.  
Then make sure you run init_globals() before running main().  
Unfortunately, there are more problems, so forget this "solution."

Third problem with globals is involved in refactoring.  When you first 
write a glob of code, you tend to put lots in one module.  Then when you 
better understand it, you refactor it into separate modules.  If it was 
coded with globals, this refactoring is much more painful.

Fourth problem with globals is in multithreading.  Any reference to 
mutable shared information has to be considered carefully, and each 
global is a potential hazard.

So, are there uses for globals?  Certainly.   First use, simple utility 
programs that fit in one file, run non-interactively, and for whom 
development pretty much stops when they "work."  Second, any immutable 
variable, whether or not it's literally protected.  There are many of 
these already in the system.  For example, all your function names are 
global variables.  Third, the system already defines some, such as in 
the sys module.  Some of these are constant, such as the path 
separator.  Others are changeable, but not usually while the application 
is running, like sys.path.

If you have to define new ones, either put them in a separate module (as 
sys does), or put them in a single class, as instance attributes.  Then, 
when refactoring, at least you only have one thing that's got to 
beshared between modules.  Any any code that refers to them will be 
using the same name for them.