warnings package might provide an Option or a pre-filled OptionParser
Currently, `warnings` uses the `-W` interpreter-level option for non-programmatic configuration. While nice, this option isn't available out of the box to scripts where the interpreter is implicit (./script.py, or `script` where it's on $PATH). I believe it would be nice if `warnings` provided something one could simply drop into `optparse` to automagically get -W handling, without having to define custom option actions every time. What do you think?
Le Fri, 19 Feb 2010 21:28:18 +0100, Masklinn a écrit :
While nice, this option isn't available out of the box to scripts where the interpreter is implicit (./script.py, or `script` where it's on $PATH). I believe it would be nice if `warnings` provided something one could simply drop into `optparse` to automagically get -W handling, without having to define custom option actions every time.
It makes sense. Can you propose a patch on the tracker?
On 19 Feb 2010, at 21:41 , Antoine Pitrou wrote:
Le Fri, 19 Feb 2010 21:28:18 +0100, Masklinn a écrit :
While nice, this option isn't available out of the box to scripts where the interpreter is implicit (./script.py, or `script` where it's on $PATH). I believe it would be nice if `warnings` provided something one could simply drop into `optparse` to automagically get -W handling, without having to define custom option actions every time.
It makes sense. Can you propose a patch on the tracker?
I can try. Should it be for Python 3 trunk?
Le Fri, 19 Feb 2010 22:16:18 +0100, Masklinn a écrit :
While nice, this option isn't available out of the box to scripts where the interpreter is implicit (./script.py, or `script` where it's on $PATH). I believe it would be nice if `warnings` provided something one could simply drop into `optparse` to automagically get -W handling, without having to define custom option actions every time.
It makes sense. Can you propose a patch on the tracker? I can try. Should it be for Python 3 trunk?
Either 2.x trunk (the SVN trunk) or 3.x trunk (the "py3k" branch), as you prefer.
Masklinn wrote:
I believe it would be nice if `warnings` provided something one could simply drop into `optparse` to automagically get -W handling
Wouldn't this be better provided as a feature of the optparse module? Otherwise you'd be making warnings dependent on optparse, or at least having to know about it, which seems like the wrong direction for the dependency to go in. -- Greg
On 20 Feb 2010, at 23:19 , Greg Ewing wrote:
Masklinn wrote:
I believe it would be nice if `warnings` provided something one could simply drop into `optparse` to automagically get -W handling
Wouldn't this be better provided as a feature of the optparse module? Otherwise you'd be making warnings dependent on optparse, or at least having to know about it, which seems like the wrong direction for the dependency to go in.
I don't know, I'm not sure it makes much sense for optparse to start providing pre-built options for random stuff in the stdlib does it? I feel it'd be more sensible to have each module provide its own set of pre-built Options (if it applies), plus I also believe it's more sensible documentation-wise (someone reading on how warnings works would be more likely to find the Options documentation in warnings than go to optparse and get it from there). Plus — at least in the case of warnings — the option would definitely make calls to warnings's "private" functions, I believe making sections of optparse depend on implementation details of other stdlib modules would be much worse than making stdlib modules optionally depend on optparse. Finally, considering the stdlib example as an example of how to do things, would it make more sense for third-party systems/libraries to provide pre-built Options or for them to try to get their options merged into optparse? I believe the former, though I might be wrong.
Masklinn wrote:
On 20 Feb 2010, at 23:19 , Greg Ewing wrote:
I believe it would be nice if `warnings` provided something one could simply drop into `optparse` to automagically get -W handling Wouldn't this be better provided as a feature of the optparse module? Otherwise you'd be making warnings dependent on optparse, or at least having to know about it, which seems like the wrong direction for
Masklinn wrote: the dependency to go in.
I don't know, I'm not sure it makes much sense for optparse to start providing pre-built options for random stuff in the stdlib does it? I feel it'd be more sensible to have each module provide its own set of pre-built Options (if it applies), plus I also believe it's more sensible documentation-wise (someone reading on how warnings works would be more likely to find the Options documentation in warnings than go to optparse and get it from there).
Plus — at least in the case of warnings — the option would definitely make calls to warnings's "private" functions, I believe making sections of optparse depend on implementation details of other stdlib modules would be much worse than making stdlib modules optionally depend on optparse.
Finally, considering the stdlib example as an example of how to do things, would it make more sense for third-party systems/libraries to provide pre-built Options or for them to try to get their options merged into optparse?
I believe the former, though I might be wrong.
-1 on modifying either optparse or warnings. It's coupling things that don't need to be coupled. Plus, we're adding argparse. Do we really want both argparse and optparse to be coupled to warnings? Eric.
Eric Smith wrote:
Plus, we're adding argparse. Do we really want both argparse and optparse to be coupled to warnings?
I agree with Titus - with the modules being peers rather than one being obviously higher level than the other the dependency feels wrong no matter which way it runs. And I'm a core developer that's been hanging around on python-ideas for a long time* ;) That said, 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. Cheers, Nick. * Just so nobody takes that comment the wrong way, keep in mind that things like this don't actually matter all that much in most python-ideas discussions - whether or not you're talking sense is usually far more important. I just couldn't resist pointing it out after Titus's comment :) -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
On Sun, Feb 21, 2010 at 03:16:52PM +0100, Masklinn wrote:
On 20 Feb 2010, at 23:19 , Greg Ewing wrote:
Masklinn wrote:
I believe it would be nice if `warnings` provided something one could simply drop into `optparse` to automagically get -W handling
Wouldn't this be better provided as a feature of the optparse module? Otherwise you'd be making warnings dependent on optparse, or at least having to know about it, which seems like the wrong direction for the dependency to go in.
I don't know, I'm not sure it makes much sense for optparse to start providing pre-built options for random stuff in the stdlib does it? I feel it'd be more sensible to have each module provide its own set of pre-built Options (if it applies), plus I also believe it's more sensible documentation-wise (someone reading on how warnings works would be more likely to find the Options documentation in warnings than go to optparse and get it from there).
Isn't this conflating two things that don't belong together, though? warnings is a Python developer issue. optparse provides command line arguments for users to make use of. Generally, when running things from the command line, I shouldn't care about what language (or language version, or internal details of that language) I'm using. --titus -- C. Titus Brown, ctb@msu.edu
On 21 Feb 2010, at 15:28 , C. Titus Brown wrote:
warnings is a Python developer issue.
optparse provides command line arguments for users to make use of.
Generally, when running things from the command line, I shouldn't care about what language (or language version, or internal details of that language) I'm using.
There are cases where the user is a python developers and might want to manipulate warnings e.g. a web framework's development server or a pluggable tool where one is developing new plugins within the tool, in both cases the startup script is often called directly, not using an explicit python call. Though I didn't quite remember to describe those use cases when I made the initial proposal. Providing the option or not would be left at to the tool creator's judgement.
On Sun, Feb 21, 2010 at 03:39:42PM +0100, Masklinn wrote:
On 21 Feb 2010, at 15:28 , C. Titus Brown wrote:
warnings is a Python developer issue.
optparse provides command line arguments for users to make use of.
Generally, when running things from the command line, I shouldn't care about what language (or language version, or internal details of that language) I'm using.
There are cases where the user is a python developers and might want to manipulate warnings e.g. a web framework's development server or a pluggable tool where one is developing new plugins within the tool, in both cases the startup script is often called directly, not using an explicit python call. Though I didn't quite remember to describe those use cases when I made the initial proposal. Providing the option or not would be left at to the tool creator's judgement.
OK, I wouldn't be planning on using it, but I can see that it might be useful to some. I like Greg's idea of putting it into optparse over warnings because the dependency link is more appropriate; optparse is not related to language behavior, like warnings is. Plus there's been some recent movement on the idea that optparse may be deprecated (silently or otherwise...) in future Python releases. Whatever you decide, Antoine has said "go for it" -- make up a patch and see what happens ;). cheers, --titus -- C. Titus Brown, ctb@msu.edu
On 21 Feb 2010, at 16:02 , C. Titus Brown wrote:
I like Greg's idea of putting it into optparse over warnings because the dependency link is more appropriate; optparse is not related to language behavior, like warnings is.
Yeah but as I said above, I'm not sure it's optparse's role to provide pre-built/convenience options for other stdlib modules, especially given the chance those option would hit into the modules's implementation details.
Plus there's been some recent movement on the idea that optparse may be deprecated (silently or otherwise...) in future Python releases. Well I'm starting the impl on -trunk, and if optparse is deprecated in favor of argparse, I'm sure the same facilities can be built for argparse. It's not like the patch is gigantic.
Whatever you decide, Antoine has said "go for it" -- make up a patch and see what happens ;). Will do, thanks a lot.
On Sun, Feb 21, 2010 at 04:19:24PM +0100, Masklinn wrote:
On 21 Feb 2010, at 16:02 , C. Titus Brown wrote:
I like Greg's idea of putting it into optparse over warnings because the dependency link is more appropriate; optparse is not related to language behavior, like warnings is.
Yeah but as I said above, I'm not sure it's optparse's role to provide pre-built/convenience options for other stdlib modules, especially given the chance those option would hit into the modules's implementation details.
...and that's exactly why I'm not enthusiastic about your idea in the first place. I don't see it cleanly fitting in either location, which may mean the functionality doesn't belong in the stdlib at all. I'm new to python-ideas, and I'm not a python-dev committer, so this is all just my opinion. I'm going to guess that your best bet is to provide a patch which will provide a basis for substantive discussion. cheers, --titus -- C. Titus Brown, ctb@msu.edu
On 21 Feb 2010, at 17:59 , C. Titus Brown wrote:
I'm new to python-ideas, and I'm not a python-dev committer Well so and neither am I so… I'm completely open to cricicism from new-to-python-ideas-and-not-python-commiters :)
I'm going to guess that your best bet is to provide a patch which will provide a basis for substantive discussion. Which is now done with issue 7976.
participants (6)
-
Antoine Pitrou -
C. Titus Brown -
Eric Smith -
Greg Ewing -
Masklinn -
Nick Coghlan