From: Adam T. <aa-...@us...> - 2022-01-20 02:57:30
|
> I do not see the benefit in the new helper functions outweighting the refactoring effort: The functions are of most use to downstream developers, I'd argue. It provides a higher level abstraction which means you don't need to know about the internals of how `OptionParser` &c work. `get_settings_with_defaults` is tenuous, but I was trying to move to a point where the `OptionParser` and `ConfigParser` classes are only used in `docutils.frontend` -- providing a cleaner seperation of concerns and making any future refactorings easier. > could be combined with the removal of the mod_python hack. Done and pushed > frontend.OptionParser is still present (is it also fully backwards compatible?) I didn't remove it or change the name as many downstream consumers rely on it. It is fully backwards compatible, yes -- mostly due to the `settings_spec` <--> `arguments_spec` converters. It is deprecated, though (through the module level `__getattr__`). > Would it be feasible to have a minimal change where only the Values, Option, and OptionParser classes were based on "argparse" instead of "optparse" It would be very difficult. optparse makes fundamentally different assumptions than argparse, which took a while to sort out and convert. E.g. the parsing of config files, the "validator" behaviour -- there is a hack at the moment to intercept validators that downstream users have used and wrap them with an argparse `Action`. Broadly though, commit 2 ("Update to use argparse") can be made standalone if you want it to be -- I would be disapointed not to have the helper functions, but strictly they are not required. I think that is probably as minimal as it gets -- it was difficult enough to rewrite everything keeping 100% backwards compatability -- and I can't make any assumptions about which names are "safe" to remove -- e.g. I had to keep a no-op definition for `Option` as downstream users *might* use it. 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:** Mon Jan 17, 2022 12:42 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. |