explicit protocols and duck typing

[dg.google.groups]

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

 

[Arnaud Delobelle]

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

 

[Terry Reedy]

| 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)).

Why a function rather than a dict 'varindex'? The valid strings are then
varindex.keys(). You might want a build_varindex() func though.

|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.

builtin types have methods same as user types.

It is not clear from your description why there should be any restriction
on state-variable specifier other than hashable since any set of hashable
objects can be easily mapped to range(len(<specifier-set>) with a dict.

Whether you merely document the rules or write code to enforce them should
partly depends on who suffers when they are broken.

tjr