classification
Title: warnings should provide a public API for accessing its option parsing code
Type: enhancement Stage: patch review
Components: Library (Lib) Versions: Python 3.5
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: berker.peksag, brett.cannon, bruno.dupuis, eric.araujo, eric.smith, ncoghlan, r.david.murray, xmorel
Priority: normal Keywords: easy, patch

Created on 2010-02-21 16:55 by xmorel, last changed 2014-07-12 18:59 by berker.peksag.

Files
File name Uploaded Description Edit
warnings-option.diff xmorel, 2010-02-21 16:55 Addition of an Option instance to warnings for python 2's trunk.
warnings_opt_parse_API.patch bruno.dupuis, 2012-11-29 02:26 Expose command line parsing facilities review
warnings_opt_parse_API-2.patch bruno.dupuis, 2012-11-29 04:16 Added doc. review
warnings_opt_parse_API-3.patch bruno.dupuis, 2012-11-29 12:08 review
warnings_opt_parse_API-4.patch bruno.dupuis, 2012-11-29 15:46 Removed old private exception and function. Typo in the doc review
warnings_opt_parse_API-5.patch bruno.dupuis, 2012-12-01 00:02 WarningsOptParsingError -> WarningsOptionParsingError + cosmetics review
warnings_opt_parse_API-6.patch bruno.dupuis, 2012-12-01 01:04 renamed the function to parse_option review
warnings_opt_parse_API-7.patch bruno.dupuis, 2012-12-01 01:22 review
Repositories containing patches
http://hg.lisael.org/cpython#issue_7976_warnings_CLI_API
Messages (18)
msg99670 - (view) Author: Xavier Morel (xmorel) * Date: 2010-02-21 16:55
The interpreter has a -W option to manage warnings display, but when calling a development-related script (e.g. a framework's web development server) there is no way to manage these warnings without going back to calling the interpreter explicitly (``tool`` -> ``python path/to/tool``).

``warnings`` could provide an optparse.Option instance the tool maker could just drop into his OptionParser to provide a ``-W`` doing the same thing as the interpreter's.

Provided is a patch for python-trunk, if it's deemed interesting and good enough I'll check if it applies on python3-trunk (and create another patch which does if not)
msg99893 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-02-23 02:10
Hello

Here’s another idea.

I seem to remember Python warnings can be turned into logging events. If these big apps and frameworks (that already use logging) turned warnings into logging calls, standard logging configuration mecanisms could be used to achieve your goal.

Does that makes sense to anyone else?

Regards
msg99896 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-02-23 03:48
I believe the ability to log warning messages was added recently, but that it does not give you an control over what warnings are *generated*, just what happens to them (that is, allowing you to log them).

On the other hand, what is the motivation for wanting this control?  In 2.7/3.2, warnings will be silent by default.  Is it that you want the command/framework author to be able to allow users to turn warnings on?  This seems like an infrequent enough use case that it is probably better as a recipe rather than in the core (perhaps an example in the docs for warnings, but I'm not sure about that even).

In addition,
msg99897 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-02-23 03:53
Ignore the 'in addition', that was editing leftovers.
msg99921 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-02-23 14:55
I believe the OP’s request is partly motivated by the fact that there is a need to access a private function in warnings. See http://mail.python.org/pipermail/python-ideas/2010-February/006870.html where Nick Coghlan proposes that “the idea of creating a public API in the warnings module to expose the functionality of warnings._processoptions in a clean fashion seems like a reasonable idea that achieves the same goal without coupling it to a particular command line parsing approach”.
msg99930 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-02-23 15:53
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 that API could then include the recipe for using it with argparse.
msg176607 - (view) Author: Bruno Dupuis (bruno.dupuis) Date: 2012-11-29 02:26
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 and it contains "Warning" which is bad for something that raise and is not actually a warning. If someone has a better idea...

Anyway, I wrote a test case, and I'll write a short reciepe in the doc when the patch is good.

It's my very first patch for Python. Be rude, please :)
msg176608 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-11-29 02:35
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?
msg176610 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-11-29 02:38
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 don’t need prefixes when we have namespaces (i.e. modules: warnings.OptionParsingError is not ambiguous), but most other names in the modules contain “warning” so let’s keep the convention.

You will have noticed that I prefer Option to Opt :)
msg176615 - (view) Author: Bruno Dupuis (bruno.dupuis) Date: 2012-11-29 03:06
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-conservative when it comes to backward-compatibility, even for underscore names.
msg176624 - (view) Author: Bruno Dupuis (bruno.dupuis) Date: 2012-11-29 04:16
I added the documentation with a recipe.
msg176628 - (view) Author: Bruno Dupuis (bruno.dupuis) Date: 2012-11-29 04:25
É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.
msg176630 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-11-29 04:59
No problem! :)
msg176639 - (view) Author: Bruno Dupuis (bruno.dupuis) Date: 2012-11-29 12:08
Ok, changes made. I also updated the tests
msg176723 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-11-30 21:56
More comments in the review.
msg176730 - (view) Author: Bruno Dupuis (bruno.dupuis) Date: 2012-12-01 00:02
Changes made. I added the exception doc and some cosmetics
msg176731 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-12-01 00:16
Thanks!  Latest version looks good to me.  David, Nick, do you want to have a look at the patch?
msg176735 - (view) Author: Bruno Dupuis (bruno.dupuis) Date: 2012-12-01 01:04
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.
History
Date User Action Args
2014-07-12 18:59:18berker.peksagsetnosy: + berker.peksag

versions: + Python 3.5, - Python 3.4
2012-12-01 01:23:06bruno.dupuissetfiles: + warnings_opt_parse_API-7.patch
2012-12-01 01:04:59bruno.dupuissetfiles: + warnings_opt_parse_API-6.patch

messages: + msg176735
2012-12-01 00:16:07eric.araujosetmessages: + msg176731
2012-12-01 00:02:48bruno.dupuissetfiles: + warnings_opt_parse_API-5.patch

messages: + msg176730
2012-11-30 21:56:27eric.araujosetmessages: + msg176723
2012-11-29 15:46:27bruno.dupuissetfiles: + warnings_opt_parse_API-4.patch
hgrepos: + hgrepo161
2012-11-29 12:08:41bruno.dupuissetfiles: + warnings_opt_parse_API-3.patch

messages: + msg176639
2012-11-29 04:59:12eric.araujosetmessages: + msg176630
2012-11-29 04:25:41bruno.dupuissetmessages: + msg176628
2012-11-29 04:16:50bruno.dupuissetfiles: + warnings_opt_parse_API-2.patch

messages: + msg176624
2012-11-29 03:06:38bruno.dupuissetmessages: + msg176615
2012-11-29 02:38:26eric.araujosetmessages: + msg176610
2012-11-29 02:35:31eric.araujosetmessages: + msg176608
stage: needs patch -> patch review
2012-11-29 02:26:17bruno.dupuissetfiles: + warnings_opt_parse_API.patch

nosy: + bruno.dupuis
messages: + msg176607

keywords: + patch
2012-11-03 18:48:46eric.araujosetkeywords: + easy, - patch
versions: + Python 3.4, - Python 3.2
2010-11-12 01:35:15eric.araujosetstage: test needed -> needs patch
versions: - Python 2.7
2010-02-23 15:53:57r.david.murraysetpriority: low -> normal
title: warnings could provide a pre-filled -W option for third-party tools -> warnings should provide a public API for accessing its option parsing code
nosy: + ncoghlan

messages: + msg99930
2010-02-23 14:55:32eric.araujosetmessages: + msg99921
2010-02-23 03:53:44r.david.murraysetmessages: + msg99897
2010-02-23 03:48:52r.david.murraysetpriority: low
nosy: + r.david.murray, brett.cannon
messages: + msg99896

2010-02-23 02:10:17eric.araujosetnosy: + eric.araujo
messages: + msg99893
2010-02-21 18:17:46eric.smithsetstage: test needed
2010-02-21 18:14:25eric.smithsetnosy: + eric.smith
2010-02-21 16:55:32xmorelcreate