How to refer to data files without hardcoding paths?

Dave Angel davea at
Sun Sep 6 04:30:14 CEST 2009

Ben Finney wrote:
> Matthew Wilson <matt at> 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.


More information about the Python-list mailing list