This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author v+python
Recipients monkeyman79, paul.j3, r.david.murray, v+python
Date 2021-01-28.00:36:02
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1611794162.91.0.155540408211.issue42973@roundup.psfhosted.org>
In-reply-to
Content
paul j3 said:

Given how different this is from the normal argparse parsing (and the POSIX parsing argparse seeks to emulate), I question the wisdom of adding this, in part or whole, to the stock distribution.  It could certainly be published as a pypi.  That already has a number of  parsers, some built on argparse, others stand alone.


I say:

This has been a deficiency of argparse from day one. Tadek's solution seems to enable addressing the deficiency in a backward-compatible manner. Do you, paul, find any test failures? Or any incompatibilities that may not be in the test cases? If not, then it certainly does seem like a wet-blanket comment.


paul j3 forther said:

I also wonder whether it would be simpler to do this kind of parsing directly from sys.argv.  Just step through that list, consuming the values and flags in sequence.  


I say:

The whole point of argparse, and of deprecation of the prior optparse was to make more functionality available in a more powerful API. Increasing the power of the API seems to be consistent with the purpose of argparse. It took me some time and use cases to discover the limitations of argparse, and although parse_intermixed_args solved the use cases I had, I was well aware that it didn't solve cases of every existing Unix utility.
History
Date User Action Args
2021-01-28 00:36:02v+pythonsetrecipients: + v+python, r.david.murray, paul.j3, monkeyman79
2021-01-28 00:36:02v+pythonsetmessageid: <1611794162.91.0.155540408211.issue42973@roundup.psfhosted.org>
2021-01-28 00:36:02v+pythonlinkissue42973 messages
2021-01-28 00:36:02v+pythoncreate