Hi all, As I understand it, the idea behind duck typing is that you just take an object and if it has the methods you want to use you use it assuming it to be the right type of object. I'm interested in extending this idea a bit, but I feel the sort of thing I have in mind has already been thought of. So for example, in the program I'm writing a 'state variable' specifier can be either an integer or a string (the string name is mapped to an integer by another function getvarindex(name)). In this case, I can't do duck typing by seeing if the object has a method or not, because both of the types are built in types. I don't want to have to force the user to have objects like StateVariableSpecifier(name). Now at the moment, what I'm doing is accepting anything as a state variable specifier, and just passing it through the getvarindex function when I want to use it. This sort of specifies a protocol for state variable specifiers without making it explicit (like the sequence or mapping protocols built in to Python).
What I'm wondering though is whether there is any value in making this more explicit? Say, have a class which makes explicit the various relationships involved, such as that the type of a state variable specifier can be correct or incorrect (it has to be an int or a string), that the value has to be correct (the integer has to be between 0 and n for some n, and the string has to be in a dict of names), and that there is a relationship between state variable specifiers (int, string) and the underlying data type (the index of the variable in an array). Making it more explicit seems like a good idea, the question is in what way to make it more explicit. I can make it explicit just by documenting the behaviour, or I can make it explicit by adding code that enforces certain ways of using things. For this simple example, it seems like just documenting it is the best route, but I have similar issues with other more complicated parts of the code. At the moment, a model for instance can be a Model object, an Equation object or a tuple of functions, but this could be subject to change in the future. The issue I want to address is the long term maintainability of the code when possibly many people might be contributing, the transparency for other users, and the ease of documenting it. Any opinions? Dan Goodman -- http://mail.python.org/mailman/listinfo/python-list