New configuration behavior on omitted config parameters

[David García Quintas]

Accessing descriptors outside of a class doesn't work for parameters not explicitly defined in the configuration. Ie, according to UPGRADING, 

If you access settings outside of classes like this:
   Setting("setting").value
Then you should just import ginkgo and do this:
   ginkgo.settings.get("setting")

However, ginkgo.setttings.get() will return None for a "setting" not explicitly defined in the config, thus ignoring its "default" value. For example:

class C(Service):

    host = settings.setting("xmlrpc_host", default="localhost")

    port = settings.setting("xmlrpc_port", default=1729)

    server = SimpleXMLRPCServer((settings.get('xmlrpc_host'), settings.get('xmlrpc_port')) )

if no values are explicitly given in the .conf.py file for xmlrpc_host and port, settings.get(...) will be None. Config.get() only checks self._settings, but ignores self._descriptors. 

My question: is this the desired behavior or should Config.get indeed also check the defined _descriptors and return the default value if the given setting isn't found in self._settings? 

Thanks!

David.

[Jeff Lindsay]

We talked about this one a bit. Trying to register the definition defined in a descriptor for a Setting opens up to many issues (if you defined a Setting of the same name twice, what happens?). So we decided that default values are always attached to how you access them. If you want the default value described in a Setting descriptor, you should try to access it through that class/object. So yes, it's desired (or at least intentional) for the time being.

What are your thoughts?

-jeff

--
Jeff Lindsay
http://progrium.com

[David García Quintas]

The main issue I see in the current behavior is the inconsistency: ginkgo.settings.get("setting") will work if "setting" has been defined in the config and won't otherwise. Ie, behavior is modified indirectly by just the definition (or lack thereof) of a config variable. 

Addressing the problem of two Settings/descriptors with the same name, Config.setting() could check for already present descriptors with that name (or, alternatively, turn Config._descriptors into a dict, keyed by the descriptor's "path") and either complain about it or just consider the latest definition as the current/valid one. 

In sum, I see how this is problematic, but the difference in behavior depending both on whether the config variable is explicitly defined and the way the descriptor is accessed feels a bit "obscure". 

I could be missing what other issues default Setting values may cause, though. 

David.

[Jeff Lindsay]

The main issue I see in the current behavior is the inconsistency: ginkgo.settings.get("setting") will work if "setting" has been defined in the config and won't otherwise. Ie, behavior is modified indirectly by just the definition (or lack thereof) of a config variable. 

By work you mean not return None? If it's not set in configuration, wouldn't you expect it to return None? If you have a default value you want it to be, you can provide that (ie ginkgo.settings.get("setting", "default"). Maybe I'm missing something, but this doesn't seem inconsistent. 

 

Addressing the problem of two Settings/descriptors with the same name, Config.setting() could check for already present descriptors with that name (or, alternatively, turn Config._descriptors into a dict, keyed by the descriptor's "path") and either complain about it or just consider the latest definition as the current/valid one. 

In one scenario, you define Setting() twice with perhaps the same values, knowing full well one will be ignored. That seems redundant for the programmer. If they are slightly different values and Ginkgo needs to pick one, the programmer has to be aware of which one it will pick. This will lead to them having one full Setting() and then another Setting() call that just has a name, but is not dependent on a definition elsewhere. These all seem weird and awkward to me.

The current scenario is: there is a value for any setting (which may be None), and you have different ways to access it. Each way to access it has its own properties (default value, help) that can be relevant to that context. This is then consistent with using ginkgo.settings.get() ... there is no global default. If you want a global default, you define it in the configuration as a default configuration.

Feel free to rip this perspective apart if it doesn't make sense.

 

[Jeff Lindsay]

Whoops, where I say "but is not dependent on a definition elsewhere",
I mean "but is *now* dependent on a definition elsewhere"..