ethical questions about global variables

ianaré ianare at
Tue Dec 16 18:01:17 CET 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

On Dec 15, 9:45 pm, "Giampaolo Rodola'" <gne... at> wrote:
> Hi,
> in a module of mine ( 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

More information about the Python-list mailing list