|
From: Michael S. <mi...@st...> - 2011-03-01 20:13:30
|
Rich Megginson wrote: > About the arguments and return values to result4 - with the current code > I have to do something like this: > > rtype, rdata, rmsgid, decoded_serverctrls, extop_rspoid, > extop_rspval = srv.result4(msgid, 0, -1, 1) > > That is, I only want the decoded_serverctrls, but I have to add items > for extop_rspoid and extop_rspval even though I don't want them, because > result4 always returns a 6-tuple, regardless of what the caller wants. > Maybe this is the convention, to have to provide all of the optional > return values, to make it consistent that result4 always returns a > 6-tuple? Because it would be pretty easy for result4 to look at its > arguments and do something like: > if add_extop: > return a 6-tuple > else: > return a 4-tuple Look at the convenience wrapper method LDAPObject.extop_result() I've added recently. A similar method could be easily added for the case where the caller knows that one does not expect a ext op result. I consider this to be a more readable approach than looking at an argument. More ideas: I'd like to let the result-methods decode the response controls and ext op responses received. I'm thinking of adding a new optional keyword argument where one can pass in a dict([oid:class]) which can be used to automagically let the result method return instances of LDAPControl or ExtendedResponse. I'm also thinking about splitting LDAPControl into RequestControl and ResponseControl. More comments welcome. Ciao, Michael. |