[Tutor] Pythonic Style Question
Richard Damon
Richard at Damon-Family.org
Thu Jun 11 07:19:55 EDT 2020
On 6/10/20 10:03 PM, Richard Damon wrote:
> Background:
>
> Long time programmer (started with punch cards) but fairly new to punch
> cards, but fairly new to Python.
>
> Working on a program that will be a moderate size program when done, and
> doing it in Python as it looks to be a reasonable choice, and a good
> learning experience.
>
> Decided to try running pylint on it to see what sort or 'Preferred
> Style' it would lead me to (might as well have something look over the
> code and critique it) (I know the weaknesses of Linters, but worth a shot)
>
> Getting a lot of coding style errors for module global variables that
> seem to be a reasonable way to do it, but figured I would ask to see if
> there is a more Pythonic method to do these.
>
> Example, application will have a number of settings stored in a
> configuration file, so I have a myconfig.py module that is called with
> the path to the config file, that uses configparser to read in the
> options and create a module global variable (config) that other parts of
> the system can import, and then query/set by accessing.
>
> pylint first complains that these 'constants' should be in ALL_CAPS (but
> they aren't constants, so I don't think they should be ALL_CAPS), and in
> the function that will set it up, complains of the global statement so
> it can access the module global. I could also create my own access
> wrappers to get/set options, that other modules will call, but I would
> think I would still need the module global (and making it _config to
> mark it as a non-global still gets all the warnings about the constant
> not being ALL_CAPS).
>
> Is there another better way to do this sort of thing? or is pylint just
> being over picky (as lints are prone to be) and I need to put a comment
> on the statement to tell pylint it is ok?
>
For the question of sample code, showing what I am doing myconfig.py
import configparser
# Path to the currently used config file
config_path = None
# Contents of the currently used configuration
config = None
def load_configuration(path):
""" Load the Configuration file """
global config_path
config_path = path
global config
config = configparser.ConfigParser()
config.read(path)
# Add Sections we will use if not present
if 'General' not in config.sections():
config['General'] = {}
if 'Default' not in config.sections():
config['Defaults'] = {}
if 'Recent' not in config.sections():
config['Recent'] = {}
# other defaults added here
save_configuration()
def save_configuration():
""" Save the current configuration"""
with open(config_path, 'w') as configfile:
config.write(configfile)
Now, config_path probably should be _config_path as other modules
shouldn't be using it. But many modules will be doing something like
import myconfig
#
data_dir = myconfig.config['General']['DataDirectory']
To get the directory which the user has specified to put the various
data files for the program.
Yes, lots of globals are a sign of a problem, but this sort of config
data has bits for lots of parts of the program, and making each part
read its own data sounds worse, and just pushes down to problem as then
the name of the config file needs to be global, as it can be overridden
at program startup.
I suppose I could get rid of the global config statement by initializing
config to the configparser at the global level, but the None
initialization will create an error if I try to use the config
information before I call myconfig.load_configuration(). I am using a
recent version (2.5.2) but maybe the None initialization is what is
making it think it is a constant. Initializing it to the ConfigParser at
global scope does make it no longer get flagged as constant
Now, the final answer is probably adding the #pylint comments around the
sections containing the unrecognized module globals, and treat them as
the mark that I have made the deliberate decision to 'bend the rules'
(at least as interpreted by pylint).
--
Richard Damon
More information about the Tutor
mailing list