Re: Configuring an object via a dictionary

On 15/03/24 22:30, 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?

How do you define "missing"?
Thus, @Thomas' suggestion may/not apply. It is neat and easy.
I usually plump for:
self.source_name = config[ "source_name" ] or default_value
but @Grant's warning applies!
(which is why the pythonic way is to use (and test for) None as a definition of "missing" (see also impacts of using default values and mutable data-structures)
LBYL cf EAFP:
When setting-up an environment like this, elements are often set to a default-value, and then user-settings, command-line arguments, and the like, applied in a priority-order sequence, amend as-appropriate. In this way, such problems will never arise.
This is the better course 90% of the time.
Which raises the next question:
What is the impact if some attribute is "missing"? ie if the 'whatever' must be identified by source_name (for example), then there is little point in assigning any values to the new class. Considerations which apply *after* this question, the __init__(), are at least equally-important considerations (see below)!

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.

By which you mean that such "clutter" should only appear in the __init__() - which is not such a bad idea (but see below).
OTOH it is often helpful to one's comprehension to be given a prompt as to the source of the data. Thus, in later processing *config[ "source_name" ] may add a small amount of extra information to the reader, over self.source_name.
* maybe prepended "self.", or not...
Am assuming that passing all eight elements as individual arguments is off-the-table, embodying far too many 'negatives' (see below).

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?

Assuming config is a dict:
self.__dict__.update( config )
will work, but attracts similar criticism - if not "clutter" then an unnecessary view (and understanding) of the workings of classes under-the-hood.
Another question:
When these values are used, are they all used at the same time, and never again? It may only be worth 'breaking-out' and making attributes from those which are used in multiple situations within the class's methods. If, the other extreme, they are only (effectively) passed from the __init__() to some sort of open() method, then pass the data-structure as an whole and delegate/remove the "clutter" to there. In that scenario, such detail would *only* has meaning *and* purpose in the open() method and thus no point in cluttering-up the __init__() with detail that is only required elsewhere!

Or should I be doing this completely differently?

YMMV, but I prefer the idea of transferring the environment/config as a whole (as above).
If it were a class (cf the supposed dict) then "clutter" is reduced by eschewing brackets and quotation-marks, eg "config.source_name".
If those eight-elements are not the entirety of that data-structure, then consider creating an interface-class, which is extracted (or built that way) from some wider 'environment', and used to set-up access to data-source(s) or whatever. Again, this aids understanding in knowing where data has been created/gathered, and improves confidence when utilising it down-the-line.
The other principle in only providing the required (eight) items of data, is that the 'receiving-class' needs no understanding of the structure or workings of the 'sending-class' = separation of concerns, and each class has single purpose/reason to change.
A variation on that might be to use a method/function as the interface:
access = Access( config.access_data )
Thus, the config class (instance) will need an access_data method to collate the data-items. The complimentary code in this Access.__init__( self, config, ) might be something like:
(
self.source_name,
        self.server_host,
         self.server_port,
        self.user_base,
         self.user_identifier,
        self.group_base,
         self.group_identifier,
        self.owner_base = config_access()
)
If you know my style/preferences, notice that I'm breaking my own 'rule' of using named-parameters in preference to positional-parameters when there are three or more. However, this *may* be one of those exceptions (cf hobgoblins). That said, this is the third and least-preferred idea!
--
Regards,
=dn