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)

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

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,

Ignore the 'in addition', that was editing leftovers.

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”.

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.

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 :)

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?

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 :)

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.

I added the documentation with a recipe.

É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.

No problem! :)

Ok, changes made. I also updated the tests

More comments in the review.

Changes made. I added the exception doc and some cosmetics

Thanks!  Latest version looks good to me.  David, Nick, do you want to have a look at the patch?

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.

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.