Custom Search

Tuesday, March 6, 2012

Configuration with Python class objects

Another old bit of writing. While the space used for the demonstration - web applications - is now thoroughly dominated by template engines and frameworks, the core concepts are still valid. Resurrected by request.


The requirements for configuring a complex program include such things as separate namespaces for different parts of the program; the ability to configure an object as like that one, only... and the ability to create new configurations on the fly. In general, the configuration facility should provide programming language constructs for advanced users. All this should be possible while keeping the language simple enough for unsophisticated users.

Python provides a modern, object oriented language for building configuration values, with a regular and straightforward syntax. Its class objects can hold configuration information in class variables. Classes can inherit from each other, and hence can look be made to resemble each other, or prototype. Finally, classes can be instantiated to create an object that acts like a configuration object created at run time.

The configuration problem

Writing software configuration tools has always been a balancing act between the needs for power and flexibility, and the need to make program configuration simple enough for non-technical users. Much of this has been solved on the desktop with the appearance of standardized APIs and configuration wizards, but it has resurfaced with a vengeance in software for the WWW.

A typical web program consists of a collection of interfaces to data objects, which have similar but not identical configurations, accessed by users who have different capabilities - some can write, some can only read, and others can create - and different views of the same objects. Worse yet, some of the configured objects may need slightly different configurations, created dynamically at run time. This is all coupled with the need for the HTML generated by the application to be created by a nontechnical designer. Thus the HTML must be part of the configuration, not part of the source code. While a configuration wizard might be able to handle these needs, many WWW applications are custom built in a highly competitive environment that does not allow time for such frills.

Python provides a very effective tool for configuring such programs. While it may seem like overkill to use an object-oriented programming language as a configuration language, Python has a history of use as an embedded scripting language for non-technical users. See [Anderson], [Beazley] and [Hinsen] for recent examples. A little artful work with class statements allows the namespace to be partitioned. This leaves having to quote strings that would be unquoted tokens in a custom configuration language as the only serious wart.

Configuration objects as a solution

The fundamental goal of configuration is to allow the user to control the appearance and properties of the programs objects without having to write program code. In an object-oriented programming environment, the simple way to do this is to attach a configuration object to each program object, where the attributes of the configuration object are the values the program object uses to determine it's appearance and behavior.

This leads to a parallel object structure, with the programmer creating one class hierarchy and the configuration creating the second. The objects created by the programmer define behavior. The objects the configuration creates select a behavior, and control the presentation.

The configuration objects connect to each programmed object in the system in a pattern related to both the State and Command patterns [Gamma]. This pattern, which I refer to as the Configuration pattern, when combined with Python's object model, neatly solves the configuration problem.

The problem then becomes how the configuration file is used to create these objects. In general, the only objects that the python interpreter creates without programming are class objects. However, class objects have attributes that can be read just like object attributes. Since each class creates a separate namespace with a simple syntax, this makes them an ideal solution to this problem.

Details from a working example

Having described the solution, we now present it in detail with extracts from a working program that uses this method for program configuration. The program in question is a web-based chat server. All of the HTML presented by the system comes from the configuration files.

The chat servers basic interaction with the user is to present a list of rooms, each of which represents an area with some set of discussion rules. The user selects one of the rooms and is then shown the contents of the room. The first part of the room is a control panel. Part of this is used to control how the user sees the room, and part to input messages to the room and control the appearance of the input messages. The second part of the room is the list of messages that user sees.

The basic objects for this application are obvious, and implemented as you would expect. There are user objects that reflect the users control panel settings. There are message objects that are used to hold messages. There are room objects that hold specifics about the room, such as a list of active users and messages they can see.

As described above, parallel to this class hierarchy is a configuration class hierarchy. Every object in the system has a configuration object attached that control's it's behavior and presentation. Behavior is controlled by the configuration objects attribute settings. Presentation is controlled by a configuration object attribute with a string value, which uses the Python % operator, usually with the object being presented as the right operand. This means that each class needs to provide the Python dictionary interface for that operator.

The simplest object in this application is a message. The message class definition is:

class message:
 "A message in a room."
 def __init__(my, dispatch, room):
  my._user = dispatch.request.session
  my.time = time.time()
  my.fromid = my._user['userid']
  my.nickname = my._user['nickname']

  # Message text
  my.message = string.strip(dispatch.form['message'].value)
  my.text = config.message.format % my
  del my._user

 def __str__(my): return my.text

 def __getitem__(my, key):
  if key == 'time':
   return time.ctime(my.time)
  if hasattr(my,  key):
   return getattr(my, key)
  return my._user[key]

The one atypical feature of the message class is that the HTML to display is created when the object is created and then returned by the __str__ method. It does this because the HTML representation of the message never changes, and it could be displayed thousands of times. Most other objects change between displays, and hence rebuild the HTML when they are displayed.

The other features - an __str__ method to return the HTML, and __getitem__ that calculates some values, uses attributes if they exist, and otherwise pulls values from a component object - are standard for objects in this system. A typical configuration for a message is:

class message:
 format = '''%(format_image)s%(format_status)s%(face)s<br>
   %(message)s<br>From %(location)s on %(time)s
   Back to <a href="#top">top</a>.'''
 to_wrapper = '<font color=red>%s</font>'
 from_wrapper = '%s'

The format attribute is used in the class and completely controls the format of messages. Most of the values used in it come from the _user object. The two _wrapper attributes are used to wrap messages to and from a user so they can be distinguished without having to rebuild the HTML every time the message is displayed.

As can be seen, the text used to build configuration objects is relatively simple, and doesn't require programming skills. In practice, a few strings need to be quoted where they wouldn't in a custom configuration language, and the comma required to distinguish a singleton tuple from an expression are the only real drawbacks in the syntax.

Showing the flexibility of this technic calls for a larger example. In a system of chat rooms, the rooms themselves are the most important objects. They are where messages are displayed, and users move in and out of them. This particular system also provides a couple of different types of dynamically created rooms, all of which have to be dealt with.

The configuration objects to deal with a collection of rooms looks like:

class room:
 # Format to display the body of a room. Does not
 # include messages! This has title &/ name as
 # formatting items.
 body_format = '<h3 align=center id="top">%(title)s</h3>%(header)s'

 # Description of the room, displayed in body_format
 # as %(header)
 header = ""

 # Format to display the head of a room. Same
 # formatting items as above.
 head_format = '<TITLE>Chat Room - %(title)s</TITLE>'

 # Maximum number of lines/chars in a message in
 # this room. 0 or None means no limit
 maxlines = 20
 maxchars = 2000

 # How long a room will hang around unused.
 timeout = 15 * 60

# Public rooms timeout VERY SLOWLY
class public(room):
    timeout = 24 * 60 * 60

# Each room in rooms must have an entry here with a title.
# Other values for the room config can be overridden in the
# class statement for each room
class friends(room): title = "The Friends Room"
class lounge(room):
 title = "The Lounge"
 header = """<P>This room is the <b>beta</b> chat room.
  It's where we test new features before putting them
  online everywhere.</P>"""
class poetry(room):
 title = "The Poetry Room"
 maxlines = 100
 maxchars = 10000

# List rooms created at startup
rooms = (lounge, poetry, friends)

As with the message configuration object, the bulk of this configuration object is taken up with formatting the resulting HTML. A few attributes at the end control the behavior of each room. Public rooms are created on the fly, and timeout slower than the default - 24 hours instead of 5 minutes - and hence override the timeout attribute. The first real room is the Friends room, which sets the title for the room. The Lounge adds a note to the top of the room display by overriding the header attribute. The Poetry room allows very long messages by overriding both the maxlines and the maxchars attributes.

The last feature this example can illustrate is the ability to create new configurations on the fly. The chat system lets users enter a room name to create a new room dynamically. The configuration for such a room is public room configuration, with a title added. So the configuration object can be created by creating an instance of a config.public object, and then setting it's title attribute:

 newroom = room()
 newroom.config = config.public()
 newroom.config.title = newtitle

Which creates a new room and attaches a configuration object with the new title.


As can be seen, a configuration pattern combined with Pythons object model provides a solution to each element of the configuration problem. Python itself provides the configuration language and programming constructs. The Python class construct provides namespaces and the ability to create configurations that inherit from other configurations. The ability to instantiate configuration classes and change them provides this same ability dynamically.


Charles Anderson. "Experiences with Extension Programing and Scripting in Python" In Proceedings of the Sixth International Python Conference. 1997
David M. Beazley and Peter S. Lomdahl. "Feeding a Large-scale Physics Application to Python" In Proceedings of the Sixth International Python Conference. 1997
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns - Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995.
Konrad Hinsen. "The Molecular Modeling Toolkit: as case study of a large scientific application in Python" In Proceedings of the Sixth International Python Conference. 1997

Friday, March 2, 2012

The political implications of the iOS App Store

You may well be wondering how a something like an online software store can have political implications. The answer is that the infrastructure that makes it work can, at least in the ongoing war on general purpose computing. If you aren't familiar with this war, read the article.

By delivering iOS with the App Store as the only authorized means of adding software, Apple has shown that it's possible to create a popular computing platform that isn't a general-purpose computing platform. I don't believe they did this by - as Cory Doctorow claims in the above article - delivering a device with malware preinstalled. Instead, they heavily censor the software that can be installed, turning iOS devices into platforms for running a small set approved software appliances.

Implication for Apple

Computer manufacturers are normally shielded from liability for any crimes committed using their products because the computers have so many legal uses, and they can't control the software that the customer installs. Apple has lost this last claim - they exercise absolute control over the software their customers install.

At some point someone will use an iOS device and an app from the store in committing a crime. Given the deep pockets theory - which says you pay for damages depending on your ability to pay, not your responsibility - and Apples very deep pockets, some bright lawyer will decide to try and show that Apple bears some responsibility for this crime because they allowed the app to be sold in the store.

Whether Apple will lose and have to pay, or pay to make the lawsuit go away, or fight and win is yet to be seen. But the lawsuit is certainly bound to happen.

Implication for users

The unauthorized way to turn an iOS device back into a general purpose computer is to jailbreak it. That is a violation of the DMCA, but jailbreaking is currently legal because the US Copyright Office provides an exemption to the DMCA for actions required to unlock phones for use on other carriers. Since jailbreaking is required for that, it's covered.

The question at hand is - how long will that stay true once the government realizes that that exemption allows people to use iOS devices for all the illegal activities that Apple prevents? Again, the answer is unknown, but the continued existence of the exemption - which must be reviewed at regular intervals - will get less and less likely as the war goes on.

Implications for other manufacturers

Those fighting to keep the public's computers from being able to perform actions that government has been convinced are bad for the country - basically, to keep the public's computers from being general purpose computers - will love iOS and the App Store. They demonstrate that it's possible to make money building and selling computing platforms which can have arbitrary restrictions placed on what they can do.

Since Apple can do this, why can't Dell, Gateway, Microsoft, HTC, and everyone else who makes computers or operating systems? If they try and resist - which doesn't seem likely, as such stores are profit centers - I'd expect it to become a legal requirement in order to sell computers.


If you like not having the government dictate what you can and can't do with your computers, you need to support platforms that don't let anyone do that. Avoid iOS. Avoid buying software through manufacturers stores. Avoid hardware that won't let you run alternative operating systems.

In a sentence: protect your right to choose by making sure you buy and use systems that preserve it.