Ben Finney wrote:
Matthew Wilson <m...@tplus1.com> writes:
Today I realized that I'm hardcoding paths in my app. They are
relative paths based on os.getcwd(), but at some point, I'll be
running scripts that use this code, these open(...) calls will fail.
The conventional solution to this is:
* Read configuration settings, whether directory paths or anything else,
from a configuration file of declarative options.
* Have the program read that configuration file from one location (or a
small number of locations), and make those locations well-known in the
documentation of the program.
Python's standard library has the ‘configparser’ module, which is one
possible implementation of this.
Before you can decide what libraries to use, you need to determine your
goal. Usually, you can separate the data files your application uses
into two groups. One is the read-only files. Those ship with the
application, and won't be edited after installation, or if they are,
they would be deliberate changes by the administrator of the machine,
not the individual user. Those should be located with the shipped .py
and .pyc files.
The other group (which might in turn be subdivided) is files that are
either created by the application for configuration purposes (config
files), or for the user (documents), or temp files (temp).
The first files can/should be found by looking up the full path to a
module at run time. Use the module's __file__ to get the full path, and
os.path.dirname() to parse it.
The second group of files can be located by various methods, such as
using the HOMEPATH
environment variable. But if there is more than one such location, one
should generally create a config file first, and have it store the
locations of the other files, after consulting with the end-user.
Once you've thought about your goals, you should then look at supporting
libraries to help with it. configparser is one such library, though both
its name and specs have changed over the years.
DaveA
--
http://mail.python.org/mailman/listinfo/python-list
