Re: FileOptionParser and DefaultOption
Dan Gass <[email protected]> Tue, 26 Jul 2005 13:00:22 -0500
| Newsgroups | gmane.comp.python.optik.user |
|---|---|
| Message-ID | <[email protected]> |
------=_Part_2087_13682792.1122400822594 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Dirk, Thanks for your proposal. I am the author of=20 http://cfgparse.sourceforge.net/ (the standalone configuration parser that= =20 cooperates with optparse) so my thanks and a quarter probably won't even bu= y=20 you a phone call.=20 You may be interested in reading some discussion on your "marriage" between= =20 command line option parsing and configuration file parsing on the=20 configuration shootout page:=20 http://wiki.python.org/moin/ConfigParserShootout.<http://wiki.python.org/mo= in/ConfigParserShootout>When I wrote my initial marriage proposal I had some of the same thoughts as you. Because I didn't want to deal with changing the optparse interface (an= d=20 to make it more palatable to some) I chose not to subclass but rather just= =20 have the two parsers cooperate. It ended up with a very small penalty in=20 that the options need to be added to both parsers, but I do save you the=20 work of not needing to specify the help, default, typing info, etc in both= =20 places. I wrote a factory function in my toolset which set ups and return= =20 the command line and configuration file parsers in a standard way so I don'= t=20 have to repeat that logic from app to app and each app follows the same=20 paradigm. I didn't want to assume anything about how application will want= =20 to set up command line switches for controlling configuration files, keys,= =20 or help dumps so I kept that functionality out. I'm not sure where I fall on the issue today. In some respects I wouldn't= =20 mind the optparse module being able to handle both. It could further=20 simplify things a bit for the users that need them integrated. Integration= =20 of the two even simplifies it a bit for a user that even just needs one or= =20 the other because they just need to learn how to use the optparse interface= =20 and they can use it either way, althought the same pretty much holds true= =20 already for cfgparse. If optparse were to support reading configuration file options, I would=20 personally like to see most if not all the features of cfgparse in it. I'm= =20 guessing all of the contributors to the shootout page would prefer their=20 methods. So what you are proposing would require a bit of concensus buildin= g=20 which can be difficult to do. Unless of course you can convince Greg, but I= =20 suspect he has a sense of responsibility to the Python community to not add= =20 significant changes to the module without some concensus building.=20 From my perspective the standard library does not have a good configuration= =20 file parser. And the one it has certainly doesn't play well with the comman= d=20 line option parser. This would probably be the easiest way to get a descent= =20 configuration file parser into the standard distrubution which I would like= =20 to see. If one were to get this idea going I'd be willing to participate to help ge= t=20 the required features defined (and potentially implemented). I suspect=20 neither you nor I have a corner on the idea market as to what all features= =20 it should support as there are different applications with different=20 requirements. All I ask is that if all the features I need don't make it in= ,=20 don't wreck the optparse interface because I would want to use it the same= =20 way I do today. optparse should always support getting command line options= =20 and should never force you to deal with configuration files in a way it=20 thinks best. Regards, Dan Gass On 7/25/05, Dirk Groeneveld <[email protected]> wrote: >=20 > Hi! >=20 > As part of a bigger project I wrote an OptionParser class that reads > option defaults from a configuration file (in the ConfigFile way). The > configuration file itself is another command line option. Normal defaults > are still supported as before, so the order of precedence becomes > defaults, configuration file (if given), command line options, from low t= o > high. >=20 > I know about cfgparse, but the combination of optik/optparse and cfgparse > still leaves a lot of work to the user that has to be done for every > project, so I decided to not use it. >=20 > My question is if you would consider including this class into the > mainstream optik distribution. In that case I'd create some more > documentation and make a patch ... and replace tabs with spaces ;-) >=20 >=20 > As part of the same project I also wrote a class that automatically adds > information about a default to an option to the help text of that option. > For example, >=20 > parser.add_option("-t", "--timeout", type=3D"float", dest=3D"timeout", \ > metavar=3D"TIMEOUT", default=3D0.5, help=3D"timeout on the serial port") >=20 > comes out in the help text as >=20 > -t TIMEOUT, --timeout=3DTIMEOUT > timeout on the serial port. Default is 0.5. >=20 > I could prepare that one too for inclusion into optik, if someone is > interested. There is a small problem though. The class is overwriting > Option's constructor, and it should really be a mixin class. I'm not sure > there is a way to write constructor-altering mixin classes with old-style > classes. >=20 > Take care, > Dirk >=20 >=20 > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclic= k > _______________________________________________ > optik-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/optik-users > ------=_Part_2087_13682792.1122400822594 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Dirk,<br> <br> Thanks for your proposal. I am the author of <a href=3D"http://cfgparse.sourceforge.net/">http://cfgparse.sourceforge.ne= t/</a> (the standalone configuration parser that cooperates with optparse) so my thanks and a quarter probably won't even buy you a phone call. <br> <br> You may be interested in reading some discussion on your "marriage&quo= t; between command line option parsing and configuration file parsing on the configuration shootout page: <a onclick=3D"return top.js.OpenExtLink(wi= ndow,event,this)" href=3D"http://wiki.python.org/moin/ConfigParserShootout"= target=3D"_blank">http://wiki.python.org/moin/ConfigParserShootout.</a>&nb= sp; When I wrote my initial marriage proposal I had some of the same thoughts as you. Because I didn't want to deal with changing the optparse interface (and to make it more palatable to some) I chose not to subclass but rather just have the two parsers cooperate. It ended up with a very small penalty in that the options need to be added to both parsers, but I do save you the work of not needing to specify the help, default, typing info, etc in both places. I wrote a factory function in my toolset which set ups and return the command line and configuration file parsers in a standard way so I don't have to repeat that logic from app to app and each app follows the same paradigm. I didn't want to assume anything about how application will want to set up command line switches for controlling configuration files, keys, or help dumps so I kept that functionality out.<br> <br> I'm not sure where I fall on the issue today. In some respects I wouldn't mind the optparse module being able to handle both. It could further simplify things a bit for the users that need them integrated. Integration of the two even simplifies it a bit for a user that even just needs one or the other because they just need to learn how to use the optparse interface and they can use it either way, althought the same pretty much holds true already for cfgparse.<br> <br> If optparse were to support reading configuration file options, I would personally like to see most if not all the features of cfgparse in it. I'm guessing all of the contributors to the shootout page would prefer their methods. So what you are proposing would require a bit of concensus building which can be difficult to do. Unless of course you can convince Greg, but I suspect he has a sense of responsibility to the Python community to not add significant changes to the module without some concensus building. <br> <br> From my perspective the standard library does not have a good configuration file parser. And the one it has certainly doesn't play well with the command line option parser. This would probably be the easiest way to get a descent configuration file parser into the standard distrubution which I would like to see.<br> <br> If one were to get this idea going I'd be willing to participate to help get the required features defined (and potentially implemented). I suspect neither you nor I have a corner on the idea market as to what all features it should support as there are different applications with different requirements. All I ask is that if all the features I need don't make it in, don't wreck the optparse interface because I would want to use it the same way I do today. optparse should always support getting command line options and should never force you to deal with configuration files in a way it thinks best.<br> <br> Regards,<br> Dan Gass<br> <br><div><span class=3D"gmail_quote">On 7/25/05, <b class=3D"gmail_senderna= me">Dirk Groeneveld</b> <<a href=3D"mailto:[email protected]">dgroenev@uc= i.edu</a>> wrote:</span><blockquote class=3D"gmail_quote" style=3D"borde= r-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-le= ft: 1ex;"> Hi!<br><br>As part of a bigger project I wrote an OptionParser class that r= eads<br>option defaults from a configuration file (in the ConfigFile way). = The<br>configuration file itself is another command line option. Normal def= aults <br>are still supported as before, so the order of precedence becomes<br>de= faults, configuration file (if given), command line options, from low to<br= >high.<br><br>I know about cfgparse, but the combination of optik/optparse = and cfgparse <br>still leaves a lot of work to the user that has to be done for every<br= >project, so I decided to not use it.<br><br>My question is if you would co= nsider including this class into the<br>mainstream optik distribution. In t= hat case I'd create some more <br>documentation and make a patch ... and replace tabs with spaces ;-)<br>= <br><br>As part of the same project I also wrote a class that automatically= adds<br>information about a default to an option to the help text of that = option. <br>For example,<br><br>parser.add_option("-t", "--timeout&q= uot;, type=3D"float", dest=3D"timeout", \<br> &nbs= p; metavar=3D"TIMEOUT", default=3D0.5, help=3D"t= imeout on the serial port") <br><br>comes out in the help text as<br><br> -t TIMEOUT, --tim= eout=3DTIMEOUT<br> &nb= sp; = timeout on the serial port. Default is 0.5.<br><br>I could prepare that one= too for inclusion into optik, if someone is<br>interested. There is a smal= l problem though. The class is overwriting<br>Option's constructor, and it = should really be a mixin class. I'm not sure <br>there is a way to write constructor-altering mixin classes with old-sty= le<br>classes.<br><br>Take care,<br>Dirk<br><br><br>-----------------------= --------------------------------<br>SF.Net email is sponsored by: Discover = Easy Linux Migration Strategies <br>from IBM. Find simple to follow Roadmaps, straightforward articles,<br>= informative Webcasts and more! Get everything you need to get up to<br>spee= d, fast. <a href=3D"http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&= amp;op=3Dclick"> http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick</a><b= r>_______________________________________________<br>optik-users mailing li= st<br><a href=3D"mailto:[email protected]">optik-users@list= s.sourceforge.net </a><br><a href=3D"https://lists.sourceforge.net/lists/listinfo/optik-users= ">https://lists.sourceforge.net/lists/listinfo/optik-users</a><br></blockqu= ote></div><br> ------=_Part_2087_13682792.1122400822594-- ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click