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 bethard, guilherme-pg, v+python
Date 2012-03-08.18:48:53
SpamBayes Score 2.7755576e-16
Marked as misclassified No
Message-id <1331232534.96.0.764860836519.issue14191@psf.upfronthosting.co.za>
In-reply-to
Content
Ah yes, argparse had a life outside the stdlib, so now I understand your compatibility concerns.

Mind you, I think the overall technology of argparse is superior to optparse, which is why, together with the optparse deprecation, I am trying to port to use it... so consider me a fan, not an enemy.  But...

However, it seems that while the esoteric extensions required in optparse were a known incompatibility at the time the PEP was written, the incompatibility with intermixed positional and optional parameters slipped under the radar... but is actually a more serious compatibility problem for general use.

I see three possible ways forward, maybe there are others.

1) un-deprecate optparse, explaining and documenting this functional difference between optparse and argparse.  The deprecation of optparse is what makes this missing capability a bug, rather than a feature enhancement.

2) add features to argparse to make it capable of parsing all the same command lines as unextended optparse. (I'm of the opinion that folks that extended optparse can learn to extend argparse in similar or more capable manners; not having such extensions, I'm not qualified to state whether there are optparse extensions that cannot be ported to use standard or extended argparse capabilities.)  The documentation for such features should clearly state that former users of argparse may be interested in using this feature, and should state why; further, the deprecation notice in optparse should be updated to point out that porting to argparse may need to use this particular argparse capability to achieve command line compatibility with optparse, and that the capability is not available until (specified release).

3) If there is an already existing way (my t14.py is a half-hearted attempt to find it) to parse scattered positional parameters, it could be explicitly documented rather than writing new capabilities per #2.  However, since you as author jumped to the new capabilities option straightway, I suspect this is not really a possibility.


The rest of this is concerned option #2, which seems the best way forward to me, with my current knowledge.

You mention ArgumentParserAllowingOptionalsInsidePositionals and that is extremely lengthy, might I suggest something like  ArgumentParserIntermixed ?

What would be the scope of the effort, and what release(s) might be a possible target? (since it is a bug, it can be backported, but since the cure will be implemented as a new capability, that might be problematical for point releases, somehow? I'm not the expert in that area.)
History
Date User Action Args
2012-03-08 18:48:55v+pythonsetrecipients: + v+python, bethard, guilherme-pg
2012-03-08 18:48:54v+pythonsetmessageid: <1331232534.96.0.764860836519.issue14191@psf.upfronthosting.co.za>
2012-03-08 18:48:54v+pythonlinkissue14191 messages
2012-03-08 18:48:53v+pythoncreate