Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > ethical questions about global variables

Reply
Thread Tools

ethical questions about global variables

 
 
Giampaolo Rodola'
Guest
Posts: n/a
 
      12-16-2008
Hi,
in a module of mine (ftpserver.py) I'd want to add a (boolean) global
variable named "use_gmt_times" to decide whether the server has to
return times in GMT or localtime but I'm not sure if it is a good idea
because of the "ethical" doubts I'm gonna write below.

In first place I've never liked global variables too much and always
preferred per-class-instance variables instead.
The problem in my case is that I have to use such variable in two
separated classes: FTPHandler and VirtualFileSystem. Also, I want that
for no reason one class uses times in GMT and the other one local
times.

Another doubt is the naming convention. PEP-8 states that global
variables should use the lower_case_naming_convention but I've seen a
lot of library module using the UPPER_CASE_NAMING_CONVENTION. What am
I supposed to do about it?

Thanks in advance for any comment.


--- Giampaolo
http://code.google.com/p/pyftpdlib/
 
Reply With Quote
 
 
 
 
James Mills
Guest
Posts: n/a
 
      12-16-2008
On Tue, Dec 16, 2008 at 12:45 PM, Giampaolo Rodola' <(E-Mail Removed)> wrote:
> Hi,
> in a module of mine (ftpserver.py) I'd want to add a (boolean) global
> variable named "use_gmt_times" to decide whether the server has to
> return times in GMT or localtime but I'm not sure if it is a good idea
> because of the "ethical" doubts I'm gonna write below.
>
> In first place I've never liked global variables too much and always
> preferred per-class-instance variables instead.
> The problem in my case is that I have to use such variable in two
> separated classes: FTPHandler and VirtualFileSystem. Also, I want that
> for no reason one class uses times in GMT and the other one local
> times.
>
> Another doubt is the naming convention. PEP-8 states that global
> variables should use the lower_case_naming_convention but I've seen a
> lot of library module using the UPPER_CASE_NAMING_CONVENTION. What am
> I supposed to do about it?
>
> Thanks in advance for any comment.


You could always use a "config" object
that you pass around to your other objects.

--JamesMills
 
Reply With Quote
 
 
 
 
rurpy@yahoo.com
Guest
Posts: n/a
 
      12-16-2008
On Dec 15, 7:45 pm, "Giampaolo Rodola'" <(E-Mail Removed)> wrote:
> in a module of mine (ftpserver.py) I'd want to add a (boolean) global
> variable named "use_gmt_times" to decide whether the server has to
> return times in GMT or localtime but I'm not sure if it is a good idea
> because of the "ethical" doubts I'm gonna write below.
>
> In first place I've never liked global variables too much and always
> preferred per-class-instance variables instead.


By "per-class-instance variables", you are talking
about instance attributes? I.e. "self.use_gmt_times"?
I don't see much difference between global variables
and instance attributes. One of the main problems
that make global variables bad is that they can be
referenced and set anywhere in a program, so it can
be very difficult, when one finds a global has a
wrong value at some point, to figure out how it got
that value.

Consider the following:

~~~ Snippet 1 ~~~
#my_module
def func1():
global A
A = 1
def func2
global A
A = 2
def func3
global A #Yes, this is redundant
print A

~~~ Snippet 2 ~~~
class my_class:
def func1():
self.A = 1
def func2
self.A = 2
def func3
print self.A

What's the difference between snippet 1 and
snippet 2? In the snippet 1, one says "global A";
in the snippet 2, "self." -- in this case it is
just a spelling difference. If globals are "evil"
then so must be the isomorphic use of attributes
in snippet 2.

I suppose one can say that classes are generally
smaller than modules so that the "globalish" aspect
of attributes is acceptable. But then one must
conclude that the prohibition against using globals
also applies to using instance attributes in large
classes. Or conversely, that globals are perfectly
acceptable, even desirable, in small modules.

Note also that the common workaround to eliminate
globals, passing them as arguments, doesn't really
change anything either:

#my_module
class Config: pass
config = Config()

def func1(state):
config.A = 1
def func2(state)
config.A = 2
def func3(state)
print config.A

In other words, it is not the "global" keyword
that causes problems, it is the anti-pattern
of making a variable accessible in a read/write
manner to a large number of functions without
much control over who can change it or when.
That anti-pattern can exist with globals, with
instance attributes, or with function arguments.
Simply avoiding globals is not sufficient to avoid
the anti-pattern.

> The problem in my case is that I have to use such variable in two
> separated classes: FTPHandler and VirtualFileSystem. Also, I want that
> for no reason one class uses times in GMT and the other one local
> times.
>
> Another doubt is the naming convention. PEP-8 states that global
> variables should use the lower_case_naming_convention but I've seen a
> lot of library module using the UPPER_CASE_NAMING_CONVENTION. What am
> I supposed to do about it?


I generally use an initial capital letter for my
global variables. I think it is useful to have
some signal that a variable may be set outside
the scope of the local function/method.
 
Reply With Quote
 
rurpy@yahoo.com
Guest
Posts: n/a
 
      12-16-2008
On Dec 15, 11:00 pm, (E-Mail Removed) wrote:
> #my_module
> class Config: pass
> config = Config()
>
> def func1(state):
> config.A = 1
> def func2(state)
> config.A = 2
> def func3(state)
> print config.A


That of course should have been:

def func1(config):
config.A = 1
def func2(config)
config.A = 2
def func3(config)
print config.A
 
Reply With Quote
 
Michele Simionato
Guest
Posts: n/a
 
      12-16-2008
On Dec 16, 3:45*am, "Giampaolo Rodola'" <(E-Mail Removed)> wrote:
> Hi,
> in a module of mine (ftpserver.py) I'd want to add a (boolean) global
> variable named "use_gmt_times" to decide whether the server has to
> return times in GMT or localtime but I'm not sure if it is a good idea
> because of the "ethical" doubts I'm gonna write below.


Global variables have a bad reputation, but they are not
so bad in Python. Notice that:

1. global variables in Python are local to the module they
are defined in;

2. class names and module names are usually global variables
and nobody complains about that.

3. if you use an ALL_CAPS convention it is quite quite clear
that you are using a global variable.

Actually the ALL_CAPS convention is for constants, but
sometimes I use it for configuration variables too, if
they are set at the beginning and they are never changed
during the running of the program. If you have more than
a single global, it makes sense to introduce a configuration
object, as others have said (this is how typically work)
but if you have a single parameter the confuguration
object is not worth the effort, IMO.

M. Simionato
 
Reply With Quote
 
Bruno Desthuilliers
Guest
Posts: n/a
 
      12-16-2008
Giampaolo Rodola' a écrit :
> Hi,
> in a module of mine (ftpserver.py) I'd want to add a (boolean) global
> variable named "use_gmt_times" to decide whether the server has to
> return times in GMT or localtime but I'm not sure if it is a good idea
> because of the "ethical" doubts I'm gonna write below.
>
> In first place I've never liked global variables too much and always
> preferred per-class-instance variables instead.
> The problem in my case is that I have to use such variable in two
> separated classes: FTPHandler and VirtualFileSystem. Also, I want that
> for no reason one class uses times in GMT and the other one local
> times.


Looks like it's more a configuration variable than a global. IOW, it's
not supposed to change during execution.

> Another doubt is the naming convention. PEP-8 states that global
> variables should use the lower_case_naming_convention but I've seen a
> lot of library module using the UPPER_CASE_NAMING_CONVENTION.


ALL_UPPER_NAMES are pseudo-constants - IOW, they are really variables
but are by convention considered as constants.

HTH
 
Reply With Quote
 
Gabriel Genellina
Guest
Posts: n/a
 
      12-16-2008
En Tue, 16 Dec 2008 00:45:05 -0200, Giampaolo Rodola' <(E-Mail Removed)>
escribió:

> Another doubt is the naming convention. PEP-8 states that global
> variables should use the lower_case_naming_convention but I've seen a
> lot of library module using the UPPER_CASE_NAMING_CONVENTION. What am
> I supposed to do about it?


Are you sure those UPPER_CASE names you've seen are actually variables? or
constants like:

CRLF = '\r\n'

(ok, it's not a true "constant" because the language doesn't prevent you
from modifying it... but the "intended usage" is to be a constant)

--
Gabriel Genellina

 
Reply With Quote
 
Giampaolo Rodola'
Guest
Posts: n/a
 
      12-16-2008
On 16 Dic, 07:23, Michele Simionato <(E-Mail Removed)>
wrote:
> On Dec 16, 3:45*am, "Giampaolo Rodola'" <(E-Mail Removed)> wrote:
>
> > Hi,
> > in a module of mine (ftpserver.py) I'd want to add a (boolean) global
> > variable named "use_gmt_times" to decide whether the server has to
> > return times in GMT or localtime but I'm not sure if it is a good idea
> > because of the "ethical" doubts I'm gonna write below.

>
> Global variables have a bad reputation, but they are not
> so bad in Python. Notice that:
>
> 1. global variables in Python are local to the module they
> * *are defined in;
>
> 2. class names and module names are usually global variables
> * *and nobody complains about that.
>
> 3. if you use an ALL_CAPS convention it is quite quite clear
> * *that you are using a global variable.
>
> Actually the ALL_CAPS convention is for constants, but
> sometimes I use it for configuration variables too, if
> they are set at the beginning and they are never changed
> during the running of the program. If you have more than
> a single global, it makes sense to introduce a configuration
> object, as others have said (this is how typically work)
> but if you have a single parameter the confuguration
> object is not worth the effort, IMO.
>
> * * * * * * * * *M. Simionato


No, all the other "configurable" variables are offered as class
attributes.


--- Giampaolo
http://code.google.com/p/pyftpdlib/
 
Reply With Quote
 
Yinon Ehrlich
Guest
Posts: n/a
 
      12-16-2008
On Dec 16, 4:45*am, "Giampaolo Rodola'" <(E-Mail Removed)> wrote:
> Hi,
> in a module of mine (ftpserver.py) I'd want to add a (boolean) global
> variable named "use_gmt_times" to decide whether the server has to
> return times in GMT or localtime but I'm not sure if it is a good idea
> because of the "ethical" doubts I'm gonna write below.
>
> In first place I've never liked global variables too much and always
> preferred per-class-instance variables instead.
> The problem in my case is that I have to use such variable in two
> separated classes: FTPHandler and VirtualFileSystem. Also, I want that
> for no reason one class uses times in GMT and the other one local
> times.
>
> Another doubt is the naming convention. PEP-8 states that global
> variables should use the lower_case_naming_convention but I've seen a
> lot of library module using the UPPER_CASE_NAMING_CONVENTION. What am
> I supposed to do about it?
>
> Thanks in advance for any comment.
>
> --- Giampaolohttp://code.google.com/p/pyftpdlib/


Note also that PEP-8 states that "_single_leading_underscore... from M
import *" does not import objects whose name starts with an
underscore"
 
Reply With Quote
 
ianaré
Guest
Posts: n/a
 
      12-16-2008
For anything more complicated than a simple script, I find it easier
to use some sort of config object. This could be a simple dictionnary
type class, where the values can be set/retrieved by the other classes
directly, or a more elaborate class including functions to set/
retrieve the variables. This way setting/retrieving can be 'smart' --
possibly looking at other variables, program states, thread count,
whatever, for the requested config option. It also allows for a lot of
expansion down the line if need be, rather than dealing with all sorts
of global variables floating around - which gets annoying pretty
quickly.


On Dec 15, 9:45*pm, "Giampaolo Rodola'" <(E-Mail Removed)> wrote:
> Hi,
> in a module of mine (ftpserver.py) I'd want to add a (boolean) global
> variable named "use_gmt_times" to decide whether the server has to
> return times in GMT or localtime but I'm not sure if it is a good idea
> because of the "ethical" doubts I'm gonna write below.
>
> In first place I've never liked global variables too much and always
> preferred per-class-instance variables instead.
> The problem in my case is that I have to use such variable in two
> separated classes: FTPHandler and VirtualFileSystem. Also, I want that
> for no reason one class uses times in GMT and the other one local
> times.
>
> Another doubt is the naming convention. PEP-8 states that global
> variables should use the lower_case_naming_convention but I've seen a
> lot of library module using the UPPER_CASE_NAMING_CONVENTION. What am
> I supposed to do about it?
>
> Thanks in advance for any comment.
>
> --- Giampaolohttp://code.google.com/p/pyftpdlib/


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
security ethical hacking and more... find the new updadtes thushara manoj Computer Security 0 04-25-2010 07:35 AM
Ethical ranking - technology sector. Me NZ Computing 0 02-09-2010 10:37 AM
OT: Fair trade, Ethical, Green etc products J Computer Support 1 01-01-2005 10:08 PM
schema for ethical codes (code of conduct)? tsolbjor XML 0 06-24-2004 10:17 AM
International shopping - is it ethical? =?UTF-8?B?UGFsaW5kcuKYu21l?= Computer Support 6 04-19-2004 08:51 PM



Advertisments