Re: [Python-Dev] PEP 389: argparse - new command line parsing module
Perhaps this is OT, but since command line parsing is part of configuration, I figure I'd throw it out there. My scripts often have configuration that the command line can override and I loosely follow the example hierarchy[0] listed in The Art of Unix Programming. Some configuration I want in a config file (but I want to override from the command line) and sometimes it's very nice to use environment variables for configuration. So I do something like this: Chaining Configuration -- Ugly code to cascade configuration >>> class Unset(object): pass >>> def cascade_value(opt=None, opt_name=None, env_name=None, cfg=None, >>> cfg_section=None, cfg_name=None, default=None): ...""" ...opt - result of OptionParser.parse_args ...opt_name - string of opt name you want to access ...""" ...# get from cmd line ...value = Unset() ...if opt and opt_name: ...try: ...value = opt.__getattr__(opt_name) ...except AttributeError, e: ...pass ...if not isinstance(value, Unset): ...return value ...# get from ENV ...if env_name: ...try: ...value = os.environ[env_name] ...except KeyError, e: ...pass ...if not isinstance(value, Unset): ...return value ...# get from config file ...if cfg and cfg_section and cfg_name: ...try: ...value = cfg.get(cfg_section, cfg_name) ...except ConfigParser.NoOptionError, e: ...pass ...if not isinstance(value, Unset): ...return value ...return default >>> cascade_value(opt=opt, opt_name='author', cfg=cfg, >>> cfg_section='Properties', cfg_name='author') 'Matt' Does anyone else have interest in such functionality? Is it outside the realm of this PEP? Ideally I'd like to have something like ``env_name``, ``config_key`` named parameters for options, then pass an optional list of configs files to the parser instance. Then rather than looking solely at command line options, argparse could also pull values from config files, then env and finally the command line. cheers, matt harrison 0 - http://www.faqs.org/docs/artu/ch10s02.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
On Mon, Sep 28, 2009 at 9:37 AM, Steven Bethard wrote: > On Mon, Sep 28, 2009 at 8:26 AM, Michael Foord > wrote: >> m h wrote: >>> >>> Perhaps this is OT, but since command line parsing is part of >>> configuration, I figure I'd throw it out there. My scripts often have >>> configuration that the command line can override and I loosely follow >>> the example hierarchy[0] listed in The Art of Unix Programming. >>> >>> Some configuration I want in a config file (but I want to override >>> from the command line) and sometimes it's very nice to use environment >>> variables for configuration. So I do something like this: >> >> Integration with command line options is an occasionally-requested feature >> for ConfigObj. I've always said I would be open to patches... >> >> In other words, yes I think there is demand for it. Whether it belongs >> *immediately* in the standard library is another matter, but if you wrote a >> layer that unified ConfigParser and argparse I think you will find that >> people use it. Having it integrated with the option parser is ideal. More people will use it if it is in the stdlib. Just like more people will use argparse. >> >> It is well outside the realm of this PEP however. > > What Michael said. ;-) If you'd like to provide a patch for argparse > that provides such functionality, I'd be happy to review it. > Patch submitted [0]. Accidentally marked as "Defect" instead of enhancement. Comments/critiques welcome. 0 - http://code.google.com/p/argparse/issues/detail?id=35&q=label%3AType-Defect Cheers, -matt > Steve > -- > Where did you get that preposterous hypothesis? > Did Steve tell you that? > --- The Hiphopopotamus > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
On Tue, Sep 29, 2009 at 2:31 PM, Paul Moore wrote: > 2009/9/28 Yuvgoog Greenle : >> 1. There is no chance of the script killing itself. In argparse and optparse >> exit() is called on every parsing error (btw because of this it sucks to >> debug parse_args in an interpreter). > > That one does worry me. I'd rather argparse (or any library function) > didn't call sys.exit on my behalf - it should raise an exception. Is > it actually true that argparse exits? (I can imagine that it might if > --help was specified, for example. An exception may not be right here, > but I still don't like the idea of a straight exit - I've used too > many C libraries that think they know when I want to exit). > +1 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Tracing at a more granular level (branch coverage)
Howdy Folks- I hope this is not too off topic. Sadly the current sys.settrace only allows tracing at the line level. This isn't sufficient to do branch and path coverage. The main problem is that many boolean operations can appear on a single line, and so you can't be sure which conditional branch was taken using the current tracing method. After speaking about code complexity/testing at Pycon [0], with a few people there, and seeing a few people have made some strides or shown interested in metrics/code graphs/flow and branch coverage I think that there is interest in this. One proposed method of getting branch coverage was to use Dalke's Python4Ply [1] to translate code so that all branches occur on their own line. Then using line coverage on that and converting it back to branch coverage of the original code. The maintainer of coverage.py suggested that we look into patching python instead to trace at a more granular level. His feeling was that there would be too many corner cases and the translation would get hairy quite quickly. Sadly in my 8 years of python experience I've yet to touch any c based guts of python. I'm looking for advice on how to get finer grain tracing with sys.settrace. Any advice or suggestions? There is a quorum of people (at least 5 others) who would be very interested in this functionality because it could lead to some cool tools built on top of it. (With the end goal that python code be cleaner, simpler and better tested). thanks much, -matt harrison 0 - http://panela.blog-city.com/pycon_2008_managing_complexity_slides.htm 1 - http://www.dalkescientific.com/Python/python4ply.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
