[Python-Announce] cfgparse v01_00 released
I'm pleased to announce the initial release of cfgparse (V01_00) Background - cfgparse is a more convenient, flexible, and powerful module for parsing configuration files than the standard library ConfigParser module. cfgparse uses a more declarative style modelled after the popular optparse standard library module. cfgparse can optionally cooperate with the optparse module to provide coordination between command line and configuration file options. In addition, the cooperation can be used to allow the user to control features of the parser from the command line. URLs - Docs/home page: http://cfgparse.sourceforge.net/ Download: http://sourceforge.net/projects/cfgparse/ Feature Summary - + Simple ini style configuration syntax + Type checking with error handling and help messages + Help summary modelled after that in optparse + Round trip - read, modify, write configuration files with comment retention + Cooperates with optparse for configuration file options that should be overridden by command line options + Supports heirarchically organized option settings * User may store multiple option settings in a arbitrarily deep keyed dictionary. * Application uses a key list to walk into the dictionary to obtain a setting. * User controls key list with setting in configuration file. * Supports adding keys to the list through a command line option or from environment variables. + Supports allowing user control of configuration files used. * Environment variables may be used to allow user to specify a default configuration file. * Command line options to specify configuration file supported. * Configuration files may include other configuration files where where sections are read in parallel. * Configuration files may be nested heirarchically by including configuration files from within a section or subsection. + Configuration files may alternatively be written in Python. * full power and flexibility of Python available for creation of option settings * allows options settings to be real Python objects * this feature is NOT enabled by default + May be extended to support syntax such as XML. Enjoy, Dan Gass -- http://mail.python.org/mailman/listinfo/python-list
Re: cfgparse v01_00 released
> I like this, its really nice that it fits well with optparse.
Thanks.
> I read through the docs, mostly it seems very logical, the following
> things stood out to me as not really fitting:
>
> http://cfgparse.sourceforge.net/cfgparse-round-trip-set.html
> It doesn't seem logical that in order to modify the option in the
> desired section correctly, you need to pass the config file in. The
keys
> argument in the option itself should be able to determine this.
There is a lot of necessary flexibility built into the interfaces for
round trip and it sounds like it is tripping you up. The user may
choose to split their configuration up into multiple files and use
to pull it all together. When you program your application
you have a choice. Don't pass in a config file object and let it set
the option where ever the user has it --OR-- pass in the configuration
file object where you want it set and it won't matter where the user
put it. BTW, since you may not know where the user put the setting,
the set() method returns the config file object that was updated so
that you may write its contents out. I just noticed this is
undocumented and I will fix that in the next release.
> http://cfgparse.sourceforge.net/node24.html
> The use of and for quoting seems obscure. Would it not be
better
> to use pythonic triple-quoted strings?
> On first glance they look like markup tags rather than multi-line
> continuations (particularly looks like "bold").
I did consider triple quotes but decided against it for the following
reasons:
1) I couldn't think of a good way to distinguish between blocks and
verbatim blocks without it being too subtle.
2) XML encapsulation may be more understandable to the majority of end
users (of which many are not Python programmers).
3) XML offers a style that will be extensible for future additions.
I'm not opposed to changing this area but it will need good a argument
and consensus.
> The fact that lines without an equals sign are ignored seems a bit
> lenient ...
Perhaps. If I get good arguments as to why it should be more stringent
and a consensus is formed this could be changed.
> It also seems strange how different the structure is between the
> ini-style and the Python-style formats:
> http://cfgparse.sourceforge.net/cfgparse-python.html
>
> driver = 'ethernet'
> path = { 'DEFAULT' : '192.168.0.99',
> 'DEV0': '192.168.0.0',
> 'DEV1': '192.168.0.1' }
>
> Is equivalent to:
>
> [DEFAULT]
> driver = 'ethernet'
> path = 192.168.0.99
> [DEV0]
> path = 192.168.0.0
> [DEV1]
> path = 192.168.0.1
>
> I wonder whether it would be better to use Python classes to
represent
> the same thing:
>
> class DEFAULT:
>driver = 'ethernet'
>path = '192.168.0.99'
>
> class DEV0(DEFAULT):
>path = '192.168.0.0'
>
> class DEV1(DEFAULT):
>path = '192.168.0.1'
>
> This seems to me to bear more logical structure resemblance to the
> ini-style format.
Classes cannot be used because they have a restricted character set.
The INI style was implemented to be similar to what is already in the
standard library and has the benefits of simplicity yet maitains a lot
of flexibility. Because of this I'm anticipating it to be the style of
choice by the vast majority. The Python style is for power users. I
believe both styles lend themselves to visualizing how all the settings
get blended together in a master dictionary.
I'm open to tweaking the Python syntax if there are good arguments and
concensus.
> Otherwise really cool!
Thanks again for your feedback. It is appreciated. I've spent a fair
amount of time implementing and testing features that I don't really
use in order to be able to contribute this to the Python community. If
you would like to see it (or see specific features it has) in the
standard library I encourage you to make comments at
http://www.python.org/moin/ConfigParserShootout
Regards,
Dan Gass
--
http://mail.python.org/mailman/listinfo/python-list
Re: wanted: C++ parser written in Python
You can look at the techniques and regular expressions in the testgen.c.unit test module that is part of a generic test framework called TestGen. TestGen uses a parser to automatically stub / copy functions for testing purposes. The parser is capable of identifying the function/method name as well as the parameters and return type. The only caveat with using regular expressions is the function/method's closing } must be in column zero. If you figure out a different way to get around the restriction or other improvements to the parser let me know. I'm about to release a newer version, but the area that you would be looking at is not changing so I would go ahead and download the latest that is there. TestGen can be found at sourceforge.net/projects/testgen Regards, Dan Gass -- http://mail.python.org/mailman/listinfo/python-list
ANN: TestGen 0.05 C/C++ Test Generator Released
TestGen 0.05 is now available and contains significant enhancements. What's New -- Significant Enhancements/Changes 1) added manipc.py, a generic C/C++ source manipulator that can be used for function/method isolation and stubbing for the purposes of unit testing with any test framework, including CppUnit. 2) although not new (but neglected in first anouncement) this package also includes doxit.py which is used to automatically insert Doxygen comment templates into source code. Minor Enhancements/Changes 1) C/C++ stubber has index checks to prevent storage array overflows 2) added a lot of comments to the example test scripts. 3) moved all example source files into examples/source subdirectory and moved defaultConfig.py to the examples subdirectory. Bug Fixes 1) corrected undefined name problem in C/C++ source manipulator removefunction(). 2) unit test stubber didn't recognize #include of .hpp files (or any include where extension is greater than one character. 3) python unit test target - fixed so syntax error doesn't occur when no test cases. What's TestGen -- TestGen is a Python package for software testing. The package currently contains targets for unit testing C/C++. Future releases will support integration testing of C/C++ systems as well as functional testing using Python targets. - requires Python2.2 or later (it was developed on Python2.3 with some testing/verification performed with 2.2) - Python API for specification of test case setup, inputs and outputs (Python's power and flexibility can be used to generate test cases) - generates "C/C++" test code per test specifications, compiles, links, runs, and evaluates the results - provides access to C++ protected and private variables and methods - function/method stubbing (for satisfying external linkages or testing interfaces to them) - function/method remove/copy (for isolating code under test to reduce external linkage requirements) - "on the fly" code under test manipulation capability (useful for making temporary code modifications to make it testable) - convenient "C" random number function library (useful when iterating the test to get better coverage) - easy file output comparison and base lining - test expectations independently verified for successful completion. - batch facility available for running multiple test scripts (batch tests may be nested in that they may execute other batch tests) - GNU and Microsoft compilers supported (customizable for others) TestGen also includes "by products" that fall outside the main purpose of TestGen but are related or depend on TestGen (IOW, great tools that I don't want to create independent projects for yet): - manipc.py -- source code manipulator for isolating/stubbing functions and methods for test purposes. This can be used with any test framework including CppUnit. - doxit.py -- inserts Doxygen comment templates into source code for the file header as well as structures, enums, classes, functions, methods, and defines. Does not insert templates where templates already exist. Prepopulates certain fields such as function name, parameters, and return type in the template automatically. - config.py -- flexible configuration file reader (a less up to date version is also available at http://sourceforge.net/projects/config-py/. - HtmlDiff -- class that creates an HTML table showing a side by side comparison of two versions of a text (is being included in Python2.4). License --- The vast majority of TestGen is released under the GNU General Public License with the small remainder released under the MIT License. All modules should be clearly marked, if not please let me know. Download Downloads are available at the following address under the "Files" link: https://sourceforge.net/projects/testgen/ Feedback Feedback and comments (both positive and negative) are very welcome. Besides allowing me to improve this package, it also lets me know how worth while my time is spent making updates to this package publically available. Email addresses will be respected of course. Documentation is always a challenge to keep accurate and complete. If you struggle with any part of it, let me know. Better yet if you can contribute, even something as small as a clarification, that would be greatly appreciated. You may contact the author at dan.gass at gmail.com. -- http://mail.python.org/mailman/listinfo/python-list
[Python-Announce] cfgparse v01_01 released
I'm pleased to announce the V01_01 release of cfgparse. Whats New - 1) Exception argument added to the Configuration parser initializer so that exceptions may be raised when user errors are encountered instead of the default call to sys.exit() that doesn't provide traceback. 2) Error messages were enhanced giving more detailed information. Background - cfgparse is a more convenient, flexible, and powerful module for parsing configuration files than the standard library ConfigParser module. cfgparse uses a more declarative style modelled after the popular optparse standard library module. cfgparse can optionally cooperate with the optparse module to provide coordination between command line and configuration file options. In addition, the cooperation can be used to allow the user to control features of the parser from the command line. URLs - Documentation: http://cfgparse.sourceforge.net/ Download: http://sourceforge.net/projects/cfgparse/ Feature Summary - + Simple ini style configuration syntax. + Type checking with error handling and help messages. + Help summary modelled after that in optparse. + Round trip - read, modify, write configuration files with comment retention. + Cooperates with optparse so options may be overridden from command line. + Supports heirarchically organized option settings. * User may store multiple option settings in a arbitrarily deep keyed dictionary. * Application uses a key list to walk into the dictionary to obtain a setting. * User controls key list with setting in configuration file. * Keys may be added to the list using command line or environment variables. + Supports allowing user control of configuration files used. * Environment variables may be used to specify a default configuration file. * Command line may be used to specify additional configuration files. * Configuration files may include other configuration files. + Configuration files may alternatively be written in Python. * Full power and flexibility of Python available for creation of option settings. * Allows options settings to be real Python objects. * This feature is NOT enabled by default. + May be extended to support syntax such as XML. Enjoy, Dan Gass -- http://mail.python.org/mailman/listinfo/python-list
Re: An optparse question
> No, that affects the string printed only *after* the "usage = " string. > What I would like to do is insert some string *before* the "usage = " > string, which is right after the command I type at the command prompt. > So I would like to make it look like this: The example was fine (except for a typo) as far as demonstrating the concept. Try this corrected version: from optparse import OptionParser usage = ' THIS IS NEWLY INSERTED STRING \nusage: %prog [options] input_file' parser = OptionParser(usage=usage) parser.print_help() -- http://mail.python.org/mailman/listinfo/python-list
Re: An optparse question
> Nope. That only *nearly* does what T wants. The usage message will > still be printed immediately *after* the 'usage: ' string. > > >>> parser = OptionParser(usage=usage) > >>> parser.print_help() > usage: THIS IS NEWLY INSERTED STRING > usage: lopts.py [options] input_file > > options: > -h, --help show this help message and exit Yes, I see what T meant now. Behavior expectations (assumptions) has a way of clouding one's vision. Thanks -- http://mail.python.org/mailman/listinfo/python-list
Re: self question
> cnt = 1 > def foo(): > global cnt > cnt += 1 > return cnt > > def bar(x=foo()): > print x > > bar() # 2 > bar() # 2 > bar() # 2 Looks to me like you want to use the following programming pattern to get dynamic default arguments: cnt = 1 def foo(): global cnt cnt += 1 return cnt def bar(x=None): if x is None: x = foo() print x bar() # 2 bar() # 3 bar() # 4 -- http://mail.python.org/mailman/listinfo/python-list
Making mouse wheel work with pmw ScrolledCanvas widget
Hi, I am using the pmw tkinter package and having trouble getting the ScrolledCanvas widget to respond to the mouse wheel. I am running Windows XP. I've Googled it and came up empty. I believe it should be possible because Idle's editor window supports scrolling with a mouse wheel. Thanks in advance, Dan Gass -- http://mail.python.org/mailman/listinfo/python-list
Re: Making mouse wheel work with pmw ScrolledCanvas widget
This looks like it has nothing to do with Pmw (Mega widgets) but is really a basic Tkinter problem. -- http://mail.python.org/mailman/listinfo/python-list
using breakpoints in a normal interactive session
Is there a way to temporarily halt execution of a script (without using a debugger) and have it put you in an interactive session where you have access to the locals? And possibly resume? For example: >>> def a(): ... x = 1 ... magic_breakpoint() ... y = 1 ... print "got here" ... >>> a() Traceback (most recent call last): File "", line 1, in ? File "", line 3, in a File "", line 2, in magic_breakpoint >>> x 1 >>> y Traceback (most recent call last): File "", line 1, in ? NameError: name 'y' is not defined >>> magic_resume() got here >>> x Traceback (most recent call last): File "", line 1, in ? NameError: name 'x' is not defined -- http://mail.python.org/mailman/listinfo/python-list
Re: using breakpoints in a normal interactive session
Carl -- Perfect! That is exactly what I want. I hoped it would be that easy. Thanks for taking the time to post the solution. -- http://mail.python.org/mailman/listinfo/python-list
Re: Which is More Efficient?
Measure it and find out. Sounds like a little investment in your time learning how to measure performance may pay dividends for you. -- http://mail.python.org/mailman/listinfo/python-list
