ConfigParser vs. import config
Question:
ConfigParser is the much debated vanilla configuration parser for Python.
However you can simply import config where config.py has python code which sets configuration parameters.
What are the proscons of these two approaches of configuration?
When should I choose each?
Answers:
“import config” is very simple, flexible and powerfull but, since it can do anything, it might be dangerous if the config.py is not in a safe place.
IMO it comes down to a matter of personal style. Do you intend for 3rd parties to edit your config? If so, maybe it makes sense to have a more “natural” configuration style a la ConfigParser that is not as technical and that may not be too far over the heads of your target audience.
Many popular projects such as Fabric and Django use the “native” configuration style which is essentially just a Python module. Fabry has fabfile.py and Django has settings.py.
Overall, you’re going to have a lot more flexibility using a native approach of importing a module simply because you can do anything you want in that file, including defining functions, classes, etc. because it’s just another Python module you’re importing.
This completley depends on your needs and goals for the script. One way really isnt “better”, just different. For a very detailed discussion on most of pythons config parsers (including ConfigParser and config modules), see:
The biggest issue I see with import config is that you don’t know what will happen when you import it. Yes, you will get a set of symbols that are naturally referenced using a . style interface. But the code in the configuration file can also do who-knows-what. Now, if you completely trust your users, then allowing them to do whatever they feel like in the config file is possibly a good thing. However, if you have unknown quantities, or you want to protect users from themselves, then having a configuration file in a more traditional format will be safer and more secure.
ConfigParser is the much debated vanilla configuration parser for Python.
However you can simply import config where config.py has python code which sets configuration parameters.
What are the proscons of these two approaches of configuration?
When should I choose each?
“import config” is very simple, flexible and powerfull but, since it can do anything, it might be dangerous if the config.py is not in a safe place.
IMO it comes down to a matter of personal style. Do you intend for 3rd parties to edit your config? If so, maybe it makes sense to have a more “natural” configuration style a la ConfigParser that is not as technical and that may not be too far over the heads of your target audience.
Many popular projects such as Fabric and Django use the “native” configuration style which is essentially just a Python module. Fabry has fabfile.py and Django has settings.py.
Overall, you’re going to have a lot more flexibility using a native approach of importing a module simply because you can do anything you want in that file, including defining functions, classes, etc. because it’s just another Python module you’re importing.
This completley depends on your needs and goals for the script. One way really isnt “better”, just different. For a very detailed discussion on most of pythons config parsers (including ConfigParser and config modules), see:
The biggest issue I see with import config is that you don’t know what will happen when you import it. Yes, you will get a set of symbols that are naturally referenced using a . style interface. But the code in the configuration file can also do who-knows-what. Now, if you completely trust your users, then allowing them to do whatever they feel like in the config file is possibly a good thing. However, if you have unknown quantities, or you want to protect users from themselves, then having a configuration file in a more traditional format will be safer and more secure.