Configuring an object via a dictionary

[Thomas Passin]

On 3/15/2024 3:09 PM, Grant Edwards via Python-list wrote:
> On 2024-03-15, Thomas Passin via Python-list <python-list at python.org> wrote:
>> On 3/15/2024 5:30 AM, Loris Bennett via Python-list wrote:
>>> Hi,
>>>
>>> I am initialising an object via the following:
>>>
>>>       def __init__(self, config):
>>>
>>>           self.connection = None
>>>
>>>           self.source_name = config['source_name']
>>>           self.server_host = config['server_host']
>>>           self.server_port = config['server_port']
>>>           self.user_base = config['user_base']
>>>           self.user_identifier = config['user_identifier']
>>>           self.group_base = config['group_base']
>>>           self.group_identifier = config['group_identifier']
>>>           self.owner_base = config['owner_base']
>>>
>>> However, some entries in the configuration might be missing.  What is
>>> the best way of dealing with this?
>>>
>>> I could of course simply test each element of the dictionary before
>>> trying to use.  I could also just write
>>>
>>>          self.config = config
>>>
>>> but then addressing the elements will add more clutter to the code.
>>>
>>> However, with a view to asking forgiveness rather than
>>> permission, is there some simple way just to assign the dictionary
>>> elements which do in fact exist to self-variables?
>>>
>>> Or should I be doing this completely differently?
>>
>>           self.source_name = config.get('source_name', default_value)
>>
>> Or, if you like this kind of expression better,
>>
>>           self.source_name = config.get('source_name') or default_value
> 
> Won't the latter version misbehave if the value of config['source_name'] has a
> "false" boolean value (e.g. "", 0, 0.0, None, [], (), {}, ...)
> 
>>>> config = {}
>>>> config['source_name'] = ""
>>>> config.get('source_name') or 'default'
> 'default'

Oh, well, picky, picky!  I've always like writing using the "or" form 
and have never gotten bit - especially for configuration-type values 
where you really do expect a non-falsey value, it's probably low risk - 
but of course, you're right. In newer code I have been putting a default 
into get().  And I suppose there is always the possibility that sometime 
in the future an "or" clause like that will be changed to return a 
Boolean, which one would expect anyway.