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 r.david.murray
Recipients Arfrever, asvetlov, bethard, r.david.murray, telmich
Date 2013-04-18.14:36:59
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1366295819.98.0.115976534719.issue16308@psf.upfronthosting.co.za>
In-reply-to
Content
Yes, just with limited amounts of attention to spare :(

This is a rather difficult situation, since it appears we inadvertently changed a behavior.  Fortunately it was in a feature release.  Unfortunately a new parameter to make a subparser required again can't be done in a bug fix release.

There seem to be two ways to handle this:

(1) accept the new feature.  Then the bug fix should be to make the traceback not happen, and we should update the docs to mention the new behavior as added in 3.3.  Then we change issue 9253 to be about adding the required to subparsers in 3.4 with a default of False.

(2) treat this as a bug.  In that case the bug fix would be to restore the old required=True behavior, and making them optional again is an enhancement for 3.4 covered by issue 9253 as is.

The issue with (1) is that the discussion in #9253 concluded that the previous default behavior was "safer" for users.

In either case, we need a unit test that tests the behavior.

I think we need input either from Steven or from other Python core devs on which way to go, because I can't make up my mind :)  A post to python-dev may be in order, since we haven't heard anything from Steven for a while now.
History
Date User Action Args
2013-04-18 14:37:00r.david.murraysetrecipients: + r.david.murray, bethard, Arfrever, asvetlov, telmich
2013-04-18 14:36:59r.david.murraysetmessageid: <1366295819.98.0.115976534719.issue16308@psf.upfronthosting.co.za>
2013-04-18 14:36:59r.david.murraylinkissue16308 messages
2013-04-18 14:36:59r.david.murraycreate