1. I say no to adding the pseudo-props as parameters. For the simple reason that i think the other way, with each prop set on its own line more readable. And that, it seems to me, in python is a valid reason! ;)
      posted by jos at 07:42:03 PM on July 25, 2004  
  2. I say allow it... it's very nice to be able to create and initialize the object in just one statement. The fact that both size and Size might be valid parameter values doesn't seem like a big deal if you document clearly that the ones that start with a capital letter are really just properties that can be set in the constructor.

      posted by Michael Chermside at 03:09:30 PM on July 26, 2004  
  3. One more vote for inclusion of such parameters in constructor. Why? because this will allow *BOTH* one line creation and multiple line creation of widgets, also I think that is closer to "batteries included" philosophy.
      posted by Peter Damoc at 06:25:19 AM on July 27, 2004  
  4. To have both (current and new situation) would be fine. But, I think the current situation is enough. A user always can write a proc or class to get the other way.
      posted by woolfy at 08:10:32 AM on July 27, 2004  
  5. The redundancy in the constructor and the clash between nomenclatures is unappealing. It would be nice, however, to have a mechanism by which "property sets" can be carried around as data and easily set. So I vote for a SetProperties and a named properties initializer argument:

    b = Button(parent, properties={
    'Size':(100, 25),


    This would also make it easier for someone to configure a portion of their GUI from a resource file.

    An option for normalizing the nomenclature is to make the properties case insensitive or to auto-translate into lowercase or mixedCase.
      posted by lx at 09:10:28 AM on July 27, 2004  
  6. Well, I like the idea of allowing it both ways. Making the properties case insensitive appeals to me also.

      posted by Ron Stephens at 09:43:57 AM on July 27, 2004  
  7. I'd vote for lowercase parameters in the constructor AND lowercase property names. :)
      posted by Jonathan Ellis at 10:46:00 AM on July 27, 2004  
  8. Re lowercase property names... There are two issues with this:

    1. wxPython objects have a lot of methods like SetXXX and GetXXX; e.g. SetSize/GetSize, SetPosition/GetPosition, etc. In Wax, there are "pseudo" properties; widget.GetSize() can be replaced by widget.Size, and widget.SetSize(x) can be replaced by widget.Size = x. In other words, we look for "Get"/"Set" plus the name. The name part of GetSize is "Size", not "size".

    2. Having property names that start with an uppercase letter allows you to add all kinds of attributes with lower case names, without having the risk of a name clash. As long as you stick to names that start with a lowercase letter, you won't accidentally overwrite any property names.

    So the current property names are probably here to stay. :)
      posted by Hans Nowak at 11:01:23 AM on July 27, 2004  
  9. I like the multi-valued SetProperties option, but not in the constructor since that would confuse properties with the window styles (eg. orientation, etc.) which must be set at construction. You still get 2-line initialization without the size/Size confusion.

    lx's idea looks like a reasonable compromise for the "batteries included" philosophy of 1-line initialization, and could achieve more compatible notation using 'dict':

    b = Button(parent,properties=dict(Size=(100, 25), Position=(20,20),BackgroundColor='yellow'))

      posted by Simon at 11:13:43 AM on July 27, 2004  
  10. I don't think that you should mix the new properties with the existing properties in the constructor. That could be confusing due to the redundancy issue. However, it is possible to still allow such properties to be included in the constructor, separated from the regular parameters.

    You could do this by adding a single parameter to each constructor. You could call this parameter 'properties', and it would contain a dictionary of property/value pairs.

    So instead of:

    b = Button(parent, Size=(100,100), Position=(10,10))

    you would have:

    b = Button(parent, properties={'Size':(100,100), 'Position':(10,10)})

    The code that parses this properties dictionary could ignore any invalid property for the current object.

    Your proposed SetProperties() method would take the same parameter:

    props = {'Size':(100, 100)}
    props['Position'] = (10, 10)

    You could write the code that parses this dictionary in such a way that would automatically assimilate new properties when they are added to the the base controls. You could actually use the same parsing routine for all the various controls, as long as they conform to the standard wx naming conventions (GetXXX and SetXXX).

    Drawbacks? Well, if you build the property dictionary right in the constructor call, it's a bit ugly, with all those colons and squigglies, but if that turns your stomach, you still have the option of building the property dictionary beforehand:

    props = {}
    props['Size'] = (100, 100)
    props['Position'] = (10, 10)
    b = Button(parent, properties=props)

    Hopefully this is some food for thought.


      posted by Peter de Tagyos at 11:18:59 AM on July 27, 2004  
  11. I am constructing an application in wxpython and
    have encountered the same problem.
    My solution is to adopt the "skin" concept I see in
    other applications.

    Basically anything that concerns the visual appearance
    of the widget I bundle up in a separate skin object.
    I have a hook into a widget to pass it an entire skin.
    This lets the skin be changed dynamically.

    Here are the advantages I see to using the skin model:
    o a new skin can be written by someone other than an app developer
    o a bunch of methods are removed from any particular widget's

    The downside is you need to construct a skin framework
    for your app.

      posted by Bob Mastors at 07:33:26 PM on July 27, 2004