Author v+python
Recipients amcnabb, bethard, docs@python, guilherme-pg, paul.j3, r.david.murray, v+python
Date 2013-04-23.08:14:52
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1366704893.04.0.909320745004.issue14191@psf.upfronthosting.co.za>
In-reply-to
Content
Very nice, Paul.

I tested that with some of my applications, and some of my test cases. All of them initially failed, because you have parse_intermixed_args returning parameters like parse_known_args instead of like parse_args. Now I can understand that might be a little confusing in msg166175, but note that the implementation is "like" a call to parse_known_args followed by a call to parse_args... strongly implying that the return should be like parse_args.

After tweaking your implementation in that regard, then I was able to get all the same applications and test cases to pass, although I haven't tried all my applications and all my test cases, as yet.

Your techniques for disabling particular parameters are pretty clever.

I think the difficult cases should raise an error. 

Firstly, parse_intermixed_args is intended to be for functional compatibility with optparse functionality, which doesn't support the difficult cases, therefore use of the difficult cases would require additional restrictions on the allowed order of options on the command line, beyond what optparse supports... this would be an application interface change, and as part of that interface change, should such happen, the flexibility of intermixing optionals and positionals can be restricted.

Secondly, if an understanding of how to define the use parse_intermixed_args with one or more of the difficult cases is reached, replacing an error case with a functional case is possible, but replacing one silent functionality with a different one is a backwards compatibility problem. Throwing an error avoids limiting a future definition of these cases.

The freedom of mixing optionals and positionals that would available in the now deprecated optparse does seem to be restored by this patch.

I look forward to seeing a revised patch, this is a very promising solution to this bug.
History
Date User Action Args
2013-04-23 08:14:53v+pythonsetrecipients: + v+python, amcnabb, bethard, r.david.murray, docs@python, paul.j3, guilherme-pg
2013-04-23 08:14:53v+pythonsetmessageid: <1366704893.04.0.909320745004.issue14191@psf.upfronthosting.co.za>
2013-04-23 08:14:53v+pythonlinkissue14191 messages
2013-04-23 08:14:52v+pythoncreate