Ok, I'm glad you guys liked that design pattern. Here are a few additional footnotes:
1. As George mentions, the order of the converters is *very* important, especially in this particular case. One might question whether '1+0j' would convert to a complex or an int - my first thought was to make it an int, but that made the example more complicated, and I didn't really need to be fussy to make the example. 2. If this were a design for a deserializer, it would be a bit poor, if only because of this order-sensitivity. Also, there is no way to reconstruct a string containing a value that maps to one of the other types, such as 'True' or '1'. A better deserialize/serialize design would support quoted strings so that a string of '"1"' would not be misinterpreted as an int. But again, I didn't want to take on deconstructing quoted strings, escaped characters, etc. But in general, when designing a deserializer/serializer, it's better to make the output more unambiguous. 3. I once had an O-O expert tell me that this was not really a Chain-of-Responsibility pattern. His take was that, in COR, each link succeeds, or calls the next link in the chain. In my design, each link is just one of a collection, and succeeds or raises an exception; the iteration is done from the calling routine. I really haven't found a name for this pattern, so I just call it "modified COR". -- Paul -- http://mail.python.org/mailman/listinfo/python-list
