While there is now support for a single default group, mysql documentation is clear that there is a cascade of groups for option settings, normally starting with [client], and including version numbers..
This allows generic settings to be overridden by specific settings, and it's an important feature when building an architecture around a mysql/mariadb environment.
A typical configuration chain may look like this.
[client] -> [mysql] -> [mysql-5.6] -> [pymysql] -> [my_custom_app]
Currently, the implementation of configparser only allows the programmer to define the default group (typically [client]) and then the group to read from [my_custom_app].
In terms of a proposed approach to the library, I suggest two changes (both backwards compatible).
(1) Extend the 'default_section' initializer such that it supports both a string (current implementation) and an iterable (ordered from specialised to general).
(2) Likewise extend the 'section' parameter of get() such that it supports both a string (current implementation) and an iterable (ordered from specialised to general), as above.
Mysql's own docs are as follows.
https://dev.mysql.com/doc/refman/8.0/en/option-files.html#option-file-syntax
"List more general option groups first and more specific groups later. For example, a [client] group is more general because it is read by all client programs, whereas a [mysqldump] group is read only by mysqldump. Options specified later override options specified earlier, so putting the option groups in the order [client], [mysqldump] enables mysqldump-specific options to override [client] options."
|
➜
