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