Personally, I vote against YAML if that means yet another dependency to Pyramid. INI works fine if you have only or mostly scalar types, json is ugly and pure Python code should work too, however I believe importing a config module would bring a lot of grief and dependency on globals, so it should be reflected into the already present settings registry.

I would however vote for a Python config module because it preserves data types. Take the already mentioned ports for example:

ports = 80, 8080,     12345

Then in the code you need something like:

ports = [int(p.strip()) for p in settings["ports"].split(",")]

which is more or less required for any config file except pure Python module. Also, perhaps there should be a hook for early configuration parsing so that any config mistakes (for instance a noninteger in the above sequence) are caught at application launch and not days into production when that particular piece of code gets executed for the first time.

In other words, I vote for Python config module, reflected into the settings registry, with an optional (for the developer) app startup hook for config parsing and validation.

.oO V Oo.


On 03/14/2011 08:21 PM, Stephen Lacy wrote:
Just my quick 2c:

YAML vs. INI?  Just use Python.

Why depend on another component and parser (think: user debugging of configuration errors with mis-typed config files).

Why fuss over "how does this support lists" and other similar issues?

And, for me, the most important issue is that when I see code like this:

PORTS = (80, 8080)

I know that I can just say something like "from config import PORTS" and access the values right in my code. That means that I can put anything I want in there (application-specific debug/logging parameters, nonstandard database connection parameters, whatever) and not have to fuss over "what the heck does the parser do with this, how do I get the parsed data, and what if the values I want aren't supported?" That means more documentation, more "accessor" code, etc.

Steve



--
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-devel?hl=en.

Reply via email to