
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.