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 amcnabb, bethard, docs@python, guilherme-pg, paul.j3, r.david.murray, v+python
Date 2013-05-07.18:50:12
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1367952613.26.0.671753949626.issue14191@psf.upfronthosting.co.za>
In-reply-to
Content
Paul, thanks for your continued work.

I had reworked your prior patch into a subclass of Argument Parser, and tweaking the code to get parse_intermixed_args to adjust the behaviors I had reported.

Now substituting exactly your more flexible new code into my subclass from your latest test_intermixed.py (you should delete your old patches), I can quickly confirm that it works with my applications that used to use my wrapper class, and expect and use intermixed functionality.

I also read through all your code and comments and it looks good to me.

Regarding parse_fallback_args, I do not see documentation for it. If that is intentional, you might want to add comments in the code regarding its use for testing only... and might want to rename it to _parse_fallback_args. I personally don't see a lot of value to the function, or the new parameter; tests for parse_intermixed_args and parse_known_intermixed_args should be (and have been, thanks) added to the tests for argparse, and should suffice for testing. In non-test code, I see no benefit: either the user uses features that are incompatible with parse_intermixed_args, and thus uses the other features of argparse, or the user, for compatibility reasons, needs to use parse_intermixed_args, and thus is prevented from successfully using the incompatible features. If I'm missing some benefit of parse_fallback_args, it should be explained in either the documentation or the comments.

Regarding the terminology: both intermixed and interspersed would be correct English words to describe the use case. So would intermingled :)

Because Stephen "blessed" intermixed, and because it is used by getopt documentation (getopt has not been deprecated, optparse has), it seems to be the best term to use. Should optparse someday be removed, along with its documentation, the use of the term interspersed would also disappear, leaving more consistency in terminology.

Alternative:

Because optparse uses "interspersed" in an API, we cannot fix it to use "intermixed". However, we could fix the uses of "intermixed" to be "interspersed" prior to or at the time of accepting your patch to argparse... afterwards, it would be too late.  Personally, I see no problem with the use of both terms in the documentation, and "intermixed" is the shortest, so I have a slight preference for that.
History
Date User Action Args
2013-05-07 18:50:13v+pythonsetrecipients: + v+python, amcnabb, bethard, r.david.murray, docs@python, paul.j3, guilherme-pg
2013-05-07 18:50:13v+pythonsetmessageid: <1367952613.26.0.671753949626.issue14191@psf.upfronthosting.co.za>
2013-05-07 18:50:13v+pythonlinkissue14191 messages
2013-05-07 18:50:12v+pythoncreate