I was reading through that code earlier today, and I assumed I was just in the wrong place. I got as far as:
and paused. I had been wondering about how user-config.py was getting imported, since that's not a valid module name. Now I know. It's not imported. It's executed. That's, um, unexpected :-)
Please forgive me if I sound a bit negative here. This is my first pywikibot project. I've used mwclient quite a bit in the past, but it's really too low level, exposing too many details of the MediaWiki API. It's also close to being abandonware, so for this project I decided it was time to give pywikibot a try.
What I'm finding with pywikibot is that the low-level stuff (Site, Page, etc) is mostly well designed and easy to work with. The level of abstraction it presents seems just about right. Exposing datetimes instead of raw mw timestamps is a win. Another win is pwb's "total" parameter to limit query results, compared to mwclient's unintuitive "limit", which is almost certainly not what you want. Those two things were what drove me to write my own mwclient wrapper library a couple of years ago. Eventually I realized I was reinventing much of pywikibot, which was silly.
However, what I keep bumping up against is that there's excessively tight coupling between the
library layer and the command-line scripting layer. I described one example of this in
T326650. This seems like a similar case. An API library really shouldn't know anything about command line flags. Or config files.
A good model is the python library's logging module. It provides the ability to read its config from a file, but there's a clean separation between that and the rest of the module. If you don't want to use the config file, you can skip it entirely and build your config via whatever method is convenient to your application. This really should work the same way.