On 12/04/2023 02.29, Loris Bennett wrote:
Hi,
Having solved my problem regarding setting up 'logger' such that it is
...
My reading suggests that setting up a module with a Config class which
can be imported by any part of the program might be a reasonable approach:
...
However, in my config file I am using sections, so 'config' is a dict of
dicts. Is there any cleverer generic way of initialising the class than
...
This seems a bit clunky, because I'll end up with something like
...
So the question is: How can I map a dict of dicts onto class attributes
in a generic way such that only code which wants to use a new
configuration parameter needs to be changed and not the Config class
itself? Or should I be doing this differently?
Note that the values from ConfigParser are all strings, so I am fine
with the attributes being strings - I'll just convert them as needed at
the point of use (but maybe there is also a better way of handling that
within a class).
Good progress!
The first achievement has been related to the (OO) concept of
"encapsulation" - collecting related data into one place.
The second, has been the making of this, globally-accessible within the
application.
The balancing-act may now have become: making sub-sets of the data
available.
Thus, describing which database server and schema/view to use is part of
the application's environment/config, just as much as the labels, eg
company name, used in the GUI or reporting. Such data has been collected
together (into a single 'source of truth'), but will be used in quite
separate and/or disparate functionality within the application.
The config file has been (sensibly) split into sections - when the code
is dealing with the DB it does not need to be concerned with
GUI-settings - or vice-versa.
Accordingly, and like any other class (encapsulation), having been
collected en-masse (or 'amassed', eg cmdLN options combined with a
JSON/YAML/.ini file's settings) the data should be delivered
appropriately. Thus, a 'getter' method (or property) to deliver the name
of the company (likely a string). The one for the database may deliver a
dict or key-value pairs which can be immediately 'pasted' into some
db-open function-call...
Such retrieval-methods will be targeted to the sub-systems of the
application. They can perform formatting and coercion tasks, as
necessary, eg construct full-name from two or more separate data-items,
eg first_name and family_name, or perhaps providing floats where the
config-collection only receives strings. (best to 'hide' all that within
the class, than require the application to deal with the 'clunkiness').
Plus, they could?should provide whatever combination of data-items is
appropriate to THAT part of the application's need for config-data or
constraints. (etc)
Stuff as much as is possible into the config class - how to collect
environment-data, and satisfying any/all demands for its use. Then, the
application can be relieved of all detail ("give me what I want"), only
asking for whatever it requires, when it requires, and in the format it
requires - tailored and ready for immediate-use...
--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list
