Open Stack

On 10/10/13 15:29 +0100, Mark McLoughlin wrote:
>Hi Flavio,
>
>On Thu, 2013-10-10 at 14:40 +0200, Flavio Percoco wrote:
>> Greetings,
>>
>> I'd like to propose to change both ListOpt and DictOpt default values
>> to [] and {} respectively. These values are, IMHO, saner defaults than
>> None for this 2 options and behavior won't be altered - unles `is not
>> None` is being used.
>>
>> Since I may be missing some history, I'd like to ask if there's a
>> reason why None was kept as the default `default` value for this 2 options?
>>
>> As mentioned above, this change may be backward incompatible in cases
>> like:
>>
>>     if conf.my_list_opt is None:
>>         ....
>>
>> Does anyone if there are cases like this?
>
>I'd need a lot of persuasion that this won't break some use of
>oslo.config somewhere. Not "why would anyone do that?" hand-waving.
>People do all sorts of weird stuff with APIs.

Agreed, that's what I'd like to find out, I'm sure there are cases
like:

    for item in conf.my_list_opt:
        ....

Which means that they're already using `default=[]` but I'm not 100%
sure about the backward incompatible change I mentioned.

>
>If people really think this is a big issue, I'd make it opt-in. Another
>boolean flag like the recently added validate_default_values.

TBH, I don't think this will be a really big issue but I'll do more
research on this if we agree the change makes sense. AFAICT, usages
like the one mentioned may result in something like:

    if conf.my_list_opt is None:
        val = [] # Or something else

    # OR

    val = conf.my_list_opt or []

In which cases, using `default=[]` would had made more sense. I
haven't done a lot of research on this yet.

>As regards bumping the major number and making incompatible changes - I
>think we should only consider that when there's a tonne of legacy
>compatibility stuff that we want to get rid of. For example, if we had a
>bunch of opt-in flags like these, then there'd come a point where we'd
>say "let's do 2.0 and clean those up". However, doing such a thing is
>disruptive and I'd only be in favour of it if the backwards compat
>support was really getting in our way.
>

Agreed here as well!

Cheers,
FF

-- 
@flaper87
Flavio Percoco