MAINT: replace optparse with argparse for 'doc' and 'tools' scripts #15702
Conversation
d7905eb to
521fd30
Compare
|
As for |
|
Since some of this touches distutils, I would like @rgommers to give his OK. |
|
Please do not touch distutils. The optparse note says "it will not be developed further" and not "it will be removed in the future", so I am comfortable leaving it as-is. |
|
@mattip why not distutils? It's still maintained. I'm only aware that npy_tempita is not to receive any maintanance. I don't understand the argument why use of deprecated modules should be left as-is, even if it's unlikely to be removed. There are clear benefits of using supported upstream modules. |
|
The module is very fragile, and due to its nature is difficult to test: it is used by many more architectures, compilers, operating systems, shells, and python variants than we can test for. Breaking it is very expensive in terms of developer time to find the fix. Even replicating the failure can be such a daunting task that we simply end up reverting the change. Then we have to try to work out which change to revert, which is also non-trivial since some users only update once every few years. We are even more unlikely to start using advanced features of argparse for the same reason. We could find out 3 years down the road that we broke someone's workflow by slightly changing some nuance in parsing command line arguments. It could take weeks to chase down the broken build with little indication that the problem is that the compiler invocation ended up having an extra space in the command, and this particular shell used to compile doesn't handle spaces. So in the balance, we would prefer not to change distutils unless motivated by a user-reported issue. |
|
Let's break this into two PRs, one for the distutils files and one for the rest. I'm not as concerned as Ralf is about fooling with distutils, I think we did alright with the subprocess change and that change had more subtle effects than this. However, I don't want to hang this PR up over the dispute. |
|
@mattip thanks for the explanation! Yes, agree about the fragility of the module, and the consequences of any misstep. However it is also a good argument to move away from deprecated modules to supported modules... |
|
Thanks @mwtoews . |
The optparse module is deprecated since Python 2.7/3.2. This PR upgrades a few scripts to use argparse.
Because these tools are not really part of the CI testing, they need some manual checks. Here is a summary for each tool:
doc/postprocess.pystill in used, and checked withGITVER=91118b3363 make htmldoc/summarize.pynot used, does not work (ModuleNotFoundErrror), and probably not used since numpy 1.7 (when e.g.doc/sphinxext/phantom_import.pyexisted); follow-up with Tool doc/summarize.py does not work #15708numpy/distutils/npy_pkg_config.pynot sure how to test from command linenumpy/distutils/system_info.pyappears to still be in-use, and works as beforetools/c_coverage/c_coverage_report.pystill in usetools/npy_tempita/__init__.pynot considered in this PR, as this module is left-alone