[issue7976] warnings should provide a public API for accessing its option parsing code

STINNER Victor added the comment: This issue is 9 years old has two patch (one having 8 versions): it's far from being "newcomer friendly", I remove the "Easy" label. -- keywords: -easy nosy: +vstinner ___ Python tracker

[issue7976] warnings should provide a public API for accessing its option parsing code

Changes by Berker Peksag : -- nosy: +berker.peksag versions: +Python 3.5 -Python 3.4 ___ Python tracker ___ ___ Python-bugs-list mailin

[issue7976] warnings should provide a public API for accessing its option parsing code

Changes by Bruno Dupuis : Added file: http://bugs.python.org/file28175/warnings_opt_parse_API-7.patch ___ Python tracker ___ ___ Python-bugs-li

[issue7976] warnings should provide a public API for accessing its option parsing code

Bruno Dupuis added the comment: corrected, I changed the name of the function to parse_option, and I kept WarningsOptionParsingError as a name for the exception. These two sound good together. -- Added file: http://bugs.python.org/file28174/warnings_opt_parse_API-6.patch _

[issue7976] warnings should provide a public API for accessing its option parsing code

Éric Araujo added the comment: Thanks! Latest version looks good to me. David, Nick, do you want to have a look at the patch? -- ___ Python tracker ___

[issue7976] warnings should provide a public API for accessing its option parsing code

Bruno Dupuis added the comment: Changes made. I added the exception doc and some cosmetics -- Added file: http://bugs.python.org/file28173/warnings_opt_parse_API-5.patch ___ Python tracker __

[issue7976] warnings should provide a public API for accessing its option parsing code

Éric Araujo added the comment: More comments in the review. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: h

[issue7976] warnings should provide a public API for accessing its option parsing code

Changes by Bruno Dupuis : -- hgrepos: +161 Added file: http://bugs.python.org/file28160/warnings_opt_parse_API-4.patch ___ Python tracker ___ _

[issue7976] warnings should provide a public API for accessing its option parsing code

Bruno Dupuis added the comment: Ok, changes made. I also updated the tests -- Added file: http://bugs.python.org/file28158/warnings_opt_parse_API-3.patch ___ Python tracker ___ __

[issue7976] warnings should provide a public API for accessing its option parsing code

Éric Araujo added the comment: No problem! :) -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[issue7976] warnings should provide a public API for accessing its option parsing code

Bruno Dupuis added the comment: Éric, I saw the `review` link just after I submited the second patch, and I read your comments. I'll do the changes. Sorry, I still have to learn the tools and processes. -- ___ Python tracker

[issue7976] warnings should provide a public API for accessing its option parsing code

Bruno Dupuis added the comment: I added the documentation with a recipe. -- Added file: http://bugs.python.org/file28154/warnings_opt_parse_API-2.patch ___ Python tracker ___

[issue7976] warnings should provide a public API for accessing its option parsing code

Bruno Dupuis added the comment: Thanks, I'll write the doc. Now, I'm not sure that keeping _OptionError as WarningsOptParsingError base class is a good idea. I can't see any use case to catch this exception outside the module and I'm quite sure nobody ever has. However, I tend to be over-cons

[issue7976] warnings should provide a public API for accessing its option parsing code

Éric Araujo added the comment: About the name: I think it’s good. “Warnings” is at the start, meaning this is related to the warnings system; an exception with “Warning” at the end would however not be good. I started to comment that the name could be just OptionParsingError, given that we d

[issue7976] warnings should provide a public API for accessing its option parsing code

Éric Araujo added the comment: Thanks! I reviewed the patch. You should have received an email, or you can follow the “review” link on the right of your patch in the list of files. Can you add documentation? -- stage: needs patch -> patch review _

[issue7976] warnings should provide a public API for accessing its option parsing code

Bruno Dupuis added the comment: Patch attached. I just exposed _setoption() as process_option() so that the user can manage execptions as she wants but she has to make his own loop. `_OptionError` is exposed as `WarningsOptParsingError`. I'm not satisfied with this name as it is quite long an

[issue7976] warnings should provide a public API for accessing its option parsing code

Changes by Éric Araujo : -- keywords: +easy -patch versions: +Python 3.4 -Python 3.2 ___ Python tracker ___ ___ Python-bugs-list mailin

[issue7976] warnings should provide a public API for accessing its option parsing code

Changes by Éric Araujo : -- stage: unit test needed -> needs patch versions: -Python 2.7 ___ Python tracker ___ ___ Python-bugs-list m

[issue7976] warnings should provide a public API for accessing its option parsing code

R. David Murray added the comment: I see. I agree with Nick, a public API function in Warnings is better than something specific to optparse or argparse. If the op (or anyone else) wants to propose a patch to create such an API (with docs and tests), that would be welcome. The docs for tha