On Jan 27, 7:10 pm, [EMAIL PROTECTED] wrote:
> 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.
I would filter uses of a state variable specifier through a 'decode'
function:
def decode_svs(svs):
for decode in decode_as_int, decode_as_str:
try:
return decode_as_int(svs)
except DecodeError:
continue
raise DecodeError("Invalid svs")
That could be done via overloading (see below)
> 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.
What does object have to promise to be able to do in order to be a
'model'?
> 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?
Maybe I'm way off mark here, but have you looked at overloading/
generic functions?
The concept is explained in PEP 3124 [http://www.python.org/dev/peps/
pep-3124/]
There's an implementation by Philip J. Eby in the svn repository:
Some documentation:
http://svn.python.org/view/sandbox/trunk/Overload3K/overloading.txt?rev=45971&view=markup
The implementation:
http://svn.python.org/view/sandbox/trunk/Overload3K/overloading.py?rev=45971&view=markup
--
http://mail.python.org/mailman/listinfo/python-list
