Configuration; wx.Config, ConfigParser...

[areohbee]

Presently I've got code using both (wx.Config & ConfigParser), and am
happy with neither.

ConfigParser: mostly just handles writing/parsing of the section
dictionaries - not that much help really.
wx.Config: handles auto-persistence which is good, but I really like
being able to get at the config file (it's backed by the registry on
Windows), and I'd like the option to startup with different config
files...
AND, perhaps most importantly:

Neither handles binding to UI, nor other program entities. Also, I
don't have enough experience to know under which circumstances repr
will produce a string representation that is reversible via eval.

I was toying with the idea of writing my own config class, which
allows for UI and other bindings via Publish/Subscribe interface or
the like, and is backed by an XML file, which somehow harnesses the
xml-rpc code to encode & decode the xml, since this I know will
properly encode/decode complex nested data structures...

Any thoughts or ideas or existing code I could borrow...
Thanks,
Rob

[Mike_Driscoll0]

I use ConfigObj myself. Here’s one geeky article on how I used it:

http://www.blog.pythonlibrary.org/2010/01/17/configobj-wxpython-geek-happiness/

I’m not sure what you mean by binding to the UI. Basically, I just extract my settings into my program as class properties and if I need to persist the changes my app makes, then I save them back to the config file(s).

• Mike

[Chris_Barker1]

Well, I'm not sure of what the OP has in mind either, but I have a vision I've been hoping to put into action one of these days.

A given application can have a lot of configuration settings. While tools like ConfigObject provide a nice easy way to save and reload them, they don't provide a way for the user to view/edit them.

In Mike's nice blog post, he shows how to do that, but it takes a fair bit of hand-written code. If your app has a half a dozen configuration settings, then no big deal, but there could be many, many, more.

So my vision is to define a set of configuration_object classes, each one representing a type of configuration data:

integer
float
string
color
etc...

each class would provide a way to persist itself and provide a GUI widget to let the user edit it.

You could then have a "configuration_sub_set" that would hold a number of these objects, and a "configuration_set" that would hold a bunch of "_sub_sets" -- at the GUI level each _sub_set would map to a panel, and the whole _set would be a notebook control.

A bunch of code to write, but once written, you could very quickly throw together a configuration system that could have a lot of elements.

To make things a bit fancier, a configuration object could be fairly smart, i.e. "an integer between 0 and 100", etc, etc.

One thing to look at for this would be Enthought's "traits" -- a "trait" is kind of a smart class attribute -- it can do things like know what range of values are valid, etc, and even cooler, there is a notification system, so you can have other classes react to a change in a given trait very easily. The system also provides a wxPython GUI for editing the trait. I don't think they have a persistence system, but you could build one pretty easily on top of traits.

http://code.enthought.com/projects/traits/

Someone has also written a system similar to what I have in mind, including editing numpy arrays, with a QT GUI -- he expressed interest in collaborating, to create a wx version that would share the same back-end, with a different GUI.

guidata

-Chris

···

On 4/4/11 9:00 AM, Mike Driscoll wrote:

I'm not sure what you mean by binding to the UI. Basically, I just
extract my settings into my program as class properties and if I need to
persist the changes my app makes, then I save them back to the config
file(s).

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

[areohbee]

Background: I'm very new to Python (& wxPython) - but not new to
programming.
Recently: I've been programming Lightroom plugins, which has a very
nice "preference" object. Simply bind a UI element to a preference and
you get instantly:

    - User entered value will be auto-saved (persistence).
    - Program changed preference value will be reflected in UI, and
vice versa (2-way binding between UI & program accessible variable).

This "preference" implementation frees the programmer from the code
that saves UI entered values into a config (file), and makes sure UI
entered values are accessible as program variables, and if changing of
program variables should be reflected in UI - it saves programmer from
having to explicitly code that up as well. Sort-of-a "bind-and-go", if
you will.

Each preference must be saved as a simple data type (ostensibly
supports Lua tables, but its extremely inefficient for some reason).

Anyway, this topic came up when I incorporated some code that had a
zillion configurable tidbits in it, none of which were being saved (it
was a UI demo). This was when I realized a general solution to "the
configuration problem" may be in order.

So, bottom line, I'm thinking:

    - somehow, just by specifying a "binding" between a UI element and
a configuration element, a user entered value will be automatically
saved. I suspect, under the hood, this would happen by a UI value
changed event notifying the configuration object somehow.
    - likewise, I'd like the configuration object to be able to notify
the UI. For example, simply reading the configuration (or otherwise
changing configured data programmatically) would also assign the
configured data to the corresponding UI elements.

So, app code can be written:

Instead of:
    - read / parse config file
    - go through items and distribute to program variables and UI
elements.
    - and when an item changes, remember to save config file...

This:
    - instantiate config object.
    - specify config elements and binding relationships.

Notes:
    - Ideally, this would support relatively large configurations
gracefully too, which would probably mean some sort of write-holdoff,
so changed values mark the configuration as "dirty" and at some point
in the near future the whole dirty mess will be written to disk
(cleansing it). I suppose another option would be to use an SQL
database and update immediately - hmm... Anyway, I dont like waiting
until closing to save config - assuming the app won't crash...

···

On Apr 4, 9:00 am, Mike Driscoll <kyoso...@gmail.com> wrote:

I use ConfigObj myself. Here's one geeky article on how I used it:

http://www.blog.pythonlibrary.org/2010/01/17/configobj-wxpython-geek-…

I'm not sure what you mean by binding to the UI. Basically, I just extract
my settings into my program as class properties and if I need to persist the
changes my app makes, then I save them back to the config file(s).

- Mike

[areohbee]

Right. ConfigParser-like objects provide rudimentary loading/saving,
but that's it. wx.Config also supports auto-persistence (you don't
have to explicitly save the config).

I was hoping for the UI connection too.

The ability for data-typing (as you were suggesting: for example, not
just "an integer", but "an integer from 1 to 100") and complex data
structure handling would be a big plus. I mean, maybe this needs not
be coded in any special fashion, other than making sure repr/eval are
properly implemented for each item. I have no experience with these so
I'm out on a limb now.

Maybe I'm trying to do too much here(?). But, I imagine a programming
environment where one can set up the config items and constraints and
create a UI for user access to configured items, and then everything
else comes for free...

···

On Apr 4, 9:59 am, Christopher Barker <Chris.Bar...@noaa.gov> wrote:

On 4/4/11 9:00 AM, Mike Driscoll wrote:

> I'm not sure what you mean by binding to the UI. Basically, I just
> extract my settings into my program as class properties and if I need to
> persist the changes my app makes, then I save them back to the config
> file(s).

Well, I'm not sure of what the OP has in mind either, but I have a
vision I've been hoping to put into action one of these days.

A given application can have a lot of configuration settings. While
tools like ConfigObject provide a nice easy way to save and reload them,
they don't provide a way for the user to view/edit them.

In Mike's nice blog post, he shows how to do that, but it takes a fair
bit of hand-written code. If your app has a half a dozen configuration
settings, then no big deal, but there could be many, many, more.

So my vision is to define a set of configuration_object classes, each
one representing a type of configuration data:

integer
float
string
color
etc...

each class would provide a way to persist itself and provide a GUI
widget to let the user edit it.

You could then have a "configuration_sub_set" that would hold a number
of these objects, and a "configuration_set" that would hold a bunch of
"_sub_sets" -- at the GUI level each _sub_set would map to a panel, and
the whole _set would be a notebook control.

A bunch of code to write, but once written, you could very quickly throw
together a configuration system that could have a lot of elements.

To make things a bit fancier, a configuration object could be fairly
smart, i.e. "an integer between 0 and 100", etc, etc.

One thing to look at for this would be Enthought's "traits" -- a "trait"
is kind of a smart class attribute -- it can do things like know what
range of values are valid, etc, and even cooler, there is a notification
system, so you can have other classes react to a change in a given trait
very easily. The system also provides a wxPython GUI for editing the
trait. I don't think they have a persistence system, but you could build
one pretty easily on top of traits.

http://code.enthought.com/projects/traits/

Someone has also written a system similar to what I have in mind,
including editing numpy arrays, with a QT GUI -- he expressed interest
in collaborating, to create a wx version that would share the same
back-end, with a different GUI.

guidata · PyPI

-Chris

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Bar...@noaa.gov

[areohbee]

The Traits project looks promising. I haven't dug deep yet, but on the
surface it looks like they are trying to accomplish exactly the same
things...

···

On Apr 4, 9:59 am, Christopher Barker <Chris.Bar...@noaa.gov> wrote:

On 4/4/11 9:00 AM, Mike Driscoll wrote:

> I'm not sure what you mean by binding to the UI. Basically, I just
> extract my settings into my program as class properties and if I need to
> persist the changes my app makes, then I save them back to the config
> file(s).

Well, I'm not sure of what the OP has in mind either, but I have a
vision I've been hoping to put into action one of these days.

A given application can have a lot of configuration settings. While
tools like ConfigObject provide a nice easy way to save and reload them,
they don't provide a way for the user to view/edit them.

In Mike's nice blog post, he shows how to do that, but it takes a fair
bit of hand-written code. If your app has a half a dozen configuration
settings, then no big deal, but there could be many, many, more.

So my vision is to define a set of configuration_object classes, each
one representing a type of configuration data:

integer
float
string
color
etc...

each class would provide a way to persist itself and provide a GUI
widget to let the user edit it.

You could then have a "configuration_sub_set" that would hold a number
of these objects, and a "configuration_set" that would hold a bunch of
"_sub_sets" -- at the GUI level each _sub_set would map to a panel, and
the whole _set would be a notebook control.

A bunch of code to write, but once written, you could very quickly throw
together a configuration system that could have a lot of elements.

To make things a bit fancier, a configuration object could be fairly
smart, i.e. "an integer between 0 and 100", etc, etc.

One thing to look at for this would be Enthought's "traits" -- a "trait"
is kind of a smart class attribute -- it can do things like know what
range of values are valid, etc, and even cooler, there is a notification
system, so you can have other classes react to a change in a given trait
very easily. The system also provides a wxPython GUI for editing the
trait. I don't think they have a persistence system, but you could build
one pretty easily on top of traits.

http://code.enthought.com/projects/traits/

Someone has also written a system similar to what I have in mind,
including editing numpy arrays, with a QT GUI -- he expressed interest
in collaborating, to create a wx version that would share the same
back-end, with a different GUI.

guidata · PyPI

-Chris

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Bar...@noaa.gov

[Chris_Barker1]

yup -- except for the persistence part, but with traits, I think it would be pretty easy to build the persistence in.

-CHB

···

On 4/4/11 3:15 PM, areohbee wrote:

The Traits project looks promising. I haven't dug deep yet, but on the
surface it looks like they are trying to accomplish exactly the same
things...

---
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

[Mike_Driscoll0]

I think you missed what I said. ConfigObj is NOT the same as Python’s builtin ConfigParser. It includes a whole lot more, like data-typing, setting minimums and maximums, validation, etc: http://www.voidspace.org.uk/python/articles/configobj.shtml

I still don’t know what a UI connection is, but I’m guessing you’d need to build a utility function for that, whatever it is.

• Mike

[Robin]

The PropertyGrid in 2.9 may help you get part of the way there.

···

On 4/4/11 3:08 PM, areohbee wrote:

Right. ConfigParser-like objects provide rudimentary loading/saving,
but that's it. wx.Config also supports auto-persistence (you don't
have to explicitly save the config).

I was hoping for the UI connection too.

The ability for data-typing (as you were suggesting: for example, not
just "an integer", but "an integer from 1 to 100") and complex data
structure handling would be a big plus. I mean, maybe this needs not
be coded in any special fashion, other than making sure repr/eval are
properly implemented for each item. I have no experience with these so
I'm out on a limb now.

Maybe I'm trying to do too much here(?). But, I imagine a programming
environment where one can set up the config items and constraints and
create a UI for user access to configured items, and then everything
else comes for free...

--
Robin Dunn
Software Craftsman

Welcome to wxPython!

[areohbee]

Mike,

Thank you for clarifying. After further consideration, I can see how
ConfigObj goes beyond ConfigParser. I will mull it over some more...

The traits project goes further still, but may be too "big" for what I
need.

The UI connection avoids having to write code like:

def OnMyVarValueChanged( self, event ):
    self.myVar = (get variable value from UI control)
    self.config['myVar'] = self.myVar
    self.config.write()

And the counterpart during init:

    self.myVar = self.config['myVar']
    self.myVarCtrl.SetValue( self.myVar )

And, instead write code during init like:

    self.myVarCtrl = wx.TextCtrl( ... )
    config.Bind( "myVar", self.myVarCtrl, self.myVar,
optionalConstraints... ) # or something like that...
    ...

The idea being to register a UI component, and maybe a "convenience"
variable, with the config object, so that the config object itself
takes the responsibility to dole out configured values to the
registered UI components and convenience variable. And, the other
part: takes responsbility for assuring changes made via the UI also
are saved in the configuration file, and are distributed to the
convenience variable.

What I may do is create a new class, or maybe better yet extend
ConfigObj directly:

class ConfigObjBinder( ConfigObj ):

   def Bind ... (see above)

In so doing, I could have the configuration data handling perks of
ConfigObj, plus the binding perks I'm after...

Know what I mean?

PS - There are projects that try to go further still by creating the
UI controls too, but I'm hand coding the UI and want it to stay that
way for now, or so I think.

Rob

···

On Apr 5, 8:55 am, Mike Driscoll <kyoso...@gmail.com> wrote:

I think you missed what I said. ConfigObj is NOT the same as Python's
builtin ConfigParser. It includes a whole lot more, like data-typing,
setting minimums and maximums, validation, etc:http://www.voidspace.org.uk/python/articles/configobj.shtml

I still don't know what a UI connection is, but I'm guessing you'd need to
build a utility function for that, whatever it is.

- Mike

[areohbee]

Thanks Robin,

I appreciate your input: I'll check into the PropertyGrid in v2.9.

Rob

···

On Apr 5, 10:13 am, Robin Dunn <ro...@alldunn.com> wrote:

On 4/4/11 3:08 PM, areohbee wrote:

> Right. ConfigParser-like objects provide rudimentary loading/saving,
> but that's it. wx.Config also supports auto-persistence (you don't
> have to explicitly save the config).

> I was hoping for the UI connection too.

> The ability for data-typing (as you were suggesting: for example, not
> just "an integer", but "an integer from 1 to 100") and complex data
> structure handling would be a big plus. I mean, maybe this needs not
> be coded in any special fashion, other than making sure repr/eval are
> properly implemented for each item. I have no experience with these so
> I'm out on a limb now.

> Maybe I'm trying to do too much here(?). But, I imagine a programming
> environment where one can set up the config items and constraints and
> create a UI for user access to configured items, and then everything
> else comes for free...

The PropertyGrid in 2.9 may help you get part of the way there.

--
Robin Dunn
Software Craftsmanhttp://wxPython.org

[Micah_Nordland]

I personally like yaml better that XML because it is easier to read and edit. I don’t know about the parsing, as I’ve only written a simple yaml parser that doesn’t support stuff like object serialization, and I’ve never tried writing a parser for xml. But, if you would like a config file that is human editable, I would use yaml,

···

–
Hi, I will kill all ads in google gmail.
They will all be dead and gone for all my emails to you. HA HA bye bye ads I just massacred you!!!

[Tim_Roberts]

Micah Nordland wrote:

I personally like yaml better that XML because it is easier to read
and edit. I don't know about the parsing, as I've only written a
simple yaml parser that doesn't support stuff like object
serialization, and I've never tried writing a parser for xml. But, if
you would like a config file that is human editable, I would use yaml,

That's a valid point. XML is robust and excruciatingly well-defined,
but unless you're steeped in it, it's not particularly easy for a human
to type while sitting at an editor. For me, I lean towards JSON for
this kind of thing, because it has become so ubiquitous, and because the
syntax is entirely Python-compatible.

···

--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

[areohbee]

Thanks Micah, & Tim.

Indeed XML is the less readable format.

In the interest of not re-inventing the wheel, I'm leaning towards one
of the already existing projects. For example:

- extending ConfigObj
  - Pros: sufficient data handling capabilities, and not too big.
  - Cons: Lacks the UI bindings.
Status: A definite possibility: I think tacking on the auto-
persistence and UI-binding would not be too big a deal.

- Using Traits:
  - Pros: includes the UI binding.
  - Cons: Kinda big & scary (more than I need, and may take longer to
get up to speed, layers of abstraction, interfaces... - maybe better
for big projects than small(?))
  - Would still need to add the auto-persistence.

I'll let ya know how it goes.

Rob

···

On Apr 6, 9:28 am, Tim Roberts <t...@probo.com> wrote:

Micah Nordland wrote:
> I personally like yaml better that XML because it is easier to read
> and edit. I don't know about the parsing, as I've only written a
> simple yaml parser that doesn't support stuff like object
> serialization, and I've never tried writing a parser for xml. But, if
> you would like a config file that is human editable, I would use yaml,

That's a valid point. XML is robust and excruciatingly well-defined,
but unless you're steeped in it, it's not particularly easy for a human
to type while sitting at an editor. For me, I lean towards JSON for
this kind of thing, because it has become so ubiquitous, and because the
syntax is entirely Python-compatible.

--
Tim Roberts, t...@probo.com
Providenza & Boekelheide, Inc.

[areohbee]

Thanks Micah, & Tim.

Indeed XML is the less readable format.

In the interest of not re-inventing the wheel, I'm leaning towards one
of the already existing projects. For example:

- extending ConfigObj
  - Pros: sufficient data handling capabilities, and not too big.
  - Cons: Lacks the UI bindings.
Status: A definite possibility: I think tacking on the auto-
persistence and UI-binding would not be too big a deal.

- Using Traits:
  - Pros: includes the UI binding.
  - Cons: Kinda big & scary (more than I need, and may take longer to
get up to speed, layers of abstraction, interfaces... - maybe better
for big projects than small(?))
  - Would still need to add the auto-persistence.

I'll let ya know how it goes.

Rob

···

On Apr 6, 9:28 am, Tim Roberts <t...@probo.com> wrote:

Micah Nordland wrote:
> I personally like yaml better that XML because it is easier to read
> and edit. I don't know about the parsing, as I've only written a
> simple yaml parser that doesn't support stuff like object
> serialization, and I've never tried writing a parser for xml. But, if
> you would like a config file that is human editable, I would use yaml,

That's a valid point. XML is robust and excruciatingly well-defined,
but unless you're steeped in it, it's not particularly easy for a human
to type while sitting at an editor. For me, I lean towards JSON for
this kind of thing, because it has become so ubiquitous, and because the
syntax is entirely Python-compatible.

--
Tim Roberts, t...@probo.com
Providenza & Boekelheide, Inc.

[Micah_Nordland]

I made a timer app with wxPython for my mom, and I did persistence with OnClose() and init()

···

–
Hi, I will kill all ads in google gmail.
They will all be dead and gone for all my emails to you. HA HA bye bye ads I just massacred you!!!

[areohbee]

So, reading config in __init__, and saving in OnClose, I assume you
mean.

I don't want to wait until closing to save stuff, but yeah...

Thanks,
Rob

···

On Apr 6, 7:03 pm, Micah Nordland <mpnordl...@gmail.com> wrote:

I made a timer app with wxPython for my mom, and I did persistence with
OnClose() and __init__()

--
Hi, I will kill all ads in google gmail.
They will all be dead and gone for all my emails to you. HA HA bye bye ads I
just massacred you!!!

[areohbee]

So, reading config in __init__, and saving in OnClose, I assume you
mean.

I don't want to wait until closing to save stuff, but yeah...

Thanks,
Rob

···

On Apr 6, 7:03 pm, Micah Nordland <mpnordl...@gmail.com> wrote:

I made a timer app with wxPython for my mom, and I did persistence with
OnClose() and __init__()

--
Hi, I will kill all ads in google gmail.
They will all be dead and gone for all my emails to you. HA HA bye bye ads I
just massacred you!!!

[Micah_Nordland]

That is what I did, but you can save when ever you want, just if you’re saving a lot of data you don’t want to do it too often

···

–
Hi, I will kill all ads in google gmail.
They will all be dead and gone for all my emails to you. HA HA bye bye ads I just massacred you!!

[areohbee]

I think I can come up with a saving strategy.

Thanks all,
Rob

···

On Apr 8, 5:13 pm, Micah Nordland <mpnordl...@gmail.com> wrote:

That is what I did, but you can save when ever you want, just if you're
saving a lot of data you don't want to do it too often

--
Hi, I will kill all ads in google gmail.
They will all be dead and gone for all my emails to you. HA HA bye bye ads I
just massacred you!!