explicit protocols and duck typing

[dg.google.groups at thesamovar.net]

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