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

[Günter M. <mi...@us...>]

Thank you again, Adam for the work on this tricky problem.

I propose a change of plan:
My original naïve idea was:
> After raising the Python dependency to >=3.7, now may be the
> right time to make the move.

In the light of the complexity and extent of the required changes, I
retract the suggestion to make the move now. The danger of accidential
breaks for 3rd party code is IMO too high for this change to be done
without any advance warning. As there is no stated removal date/version
for "optparse" we have a chance to prepare and start
warnings/deprecations now and do the actual switch later.

This would also solve us from the headache of re-implementing OptionParser on
the basis of "ArgumentParser" and break the lock on other changes
(allow to continue with code cleanup and "low hanging fruit" and prepare 0.19b).

Back to the discussion:
>> We have 3 settings sources: components, config files, command line:
>> Are settings after updating from config files still "default"
>> settings?

> You could argue yes, the settings are the default for the particular
> environment. Happy to take better suggestions, though.

I don't have a compelling name suggsestion, unfortunately, but I am
increasingly convinced that settings updated from configuration files are
not "default settings". 

In programmatic use, one can easily differentiate "defaults" fallbacks,
set by Docutils vs. "custom values", set in the configuration file 
(with the defaults as fallback).
This is less clear in command line use (where config-file-customized
values that are fed to the OptionParser/ArgumentParser as "default=...").

>> I propose a more versatile variant that allows for
>> "settings_overrides" and customization of the config file names.

> I see the idea, but I would very strongly advise against -- this is
> meant to be a simple convinience function. If the more complex
> functionality is needed later, we can always either add it to the same
> function, or add a new one. 

I agree.
So, for now future-proof access to customized settings relies on
core.Publisher methods (cf. the patch for utils/__init__.py).

I'll attach a diff between the first commit in "pull/8" and my suggestion 
together with a review.





Attachments:

- [argparse-aa.review](https://sourceforge.net/p/docutils/bugs/_discuss/thread/c76f9a2618/45c6/3ffa/7fbd/0cd9/attachment/argparse-aa.review) (2.2 kB; application/octet-stream)
- [argparse-aa-gm.diff](https://sourceforge.net/p/docutils/bugs/_discuss/thread/c76f9a2618/45c6/3ffa/7fbd/0cd9/attachment/argparse-aa-gm.diff) (27.1 kB; text/x-patch)


---

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

**Status:** open
**Created:** Thu Jan 06, 2022 03:02 PM UTC by Günter Milde
**Last Updated:** Sun Feb 20, 2022 06:14 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.