[Docutils-develop] [docutils:bugs] #441 Move from "optparse" to "argparse".

[Adam T. <aa-...@us...>]

From FR# 88

> I am just working on a way to disentangle frontend.OptionParser and frontend.ConfigParser but this is a topic for bug:#441

Sounds good -- happy to review a proposed design. 

I'd propose making the `--config` flag simply store the path to the file, and then add it to the list of config files to be read.

`get_config_file_settings` should also probably be removed from `OptionParser` -- instead a dict should be returned by `ConfigParser` and merged in.

> I didn't go into detail intentionally so as not to spark a debate about these parts, but I do think (eventually) simplifying these interactions can lead to a cleaner codebase.


> Docutils has an elaborated configuration framework which actually predates the "optparse" module. Later development of "Optik" into "optparse" and then "argparse" implemented some of the abstractions and enhancements offered by Docutils in a different way.

Ideally, we would construct a single `ArgumentParser` object and add arguments "normally" through `parser.add_argument`. The problem here is that subclasses can filter settings_spec (through filter_settings_spec). 

I've never seen this implemented in the way Docutils does it before -- if settings_spec tuples were treated as immutable, then things would be much simpler. 

________

We could also move to a model (a la stdlib `dataclasses` where we simply specify the setting name, type and default within the Component itself. The front-end tools could then use that information (or a mapping of settings to command line options or similar) to create the CLI arguments. 

I think this would be cleanest, but this cannot be done overnight.

_____

Did you have a chance to review my comments above in the previous post? It would be good to get some of this merged, or know what is blocking it // needs changing.

A



---

** [bugs:#441] Move from "optparse" to "argparse".**

**Status:** open
**Created:** Thu Jan 06, 2022 03:02 PM UTC by Günter Milde
**Last Updated:** Thu Jan 20, 2022 02:57 AM UTC
**Owner:** Günter Milde


The optparse documentation says:
> Deprecated since version 3.2: The optparse module is deprecated and will not be developed further; development will continue with the argparse module.

We are currently suppressing related deprecation warnings in the test suite.
After raising the Python dependency to >=3.7, now may be the right time to make the move.


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.