[issue25475] use argparse instead of getopt

Stéphane Wirtel added the comment: it's not for the pleasure, but there are two api for the command line. getopt and argparse. so in this case, what's the reason to keep both ? in particular if the documentation of getopt has a note with an alternative. maybe to keep the backward compatibility

[issue25475] use argparse instead of getopt

R. David Murray added the comment: This was discussed when argparse was included in the standard library, and the conclusion was that getopt serves a different purpose than argparse and should not be deprecated. argparse is mentioned as an alternative since in many cases it is to be preferred

[issue25475] use argparse instead of getopt

New submission from Stéphane Wirtel: not sure, but in the documentation, there is a note "Module argparse: Alternative command line option and argument parsing library." may be it's time to move from getopt to argparse and mark getopt as deprecated. We have to modify 45 files, but I can submit

[issue25475] use argparse instead of getopt

Stéphane Wirtel added the comment: and optparse. In fact, we have getopt, optparse and argparse. 3 API for the command line. optparse is marked as deprecated. maybe we can add getopt in this list. -- ___ Python tracker

[issue25475] use argparse instead of getopt

SilentGhost added the comment: This seems like a change for the sake of change. I think any module that requires argparse features can be moved in its own time. -- nosy: +SilentGhost resolution: -> rejected status: open -> closed ___ Python tracker