On 7/31/07, Matt Benson <[EMAIL PROTECTED]> wrote: > <scriptcondition> originally behaved such that a > default value can be declared on the task as an > attribute, and the embedded script can set the > condition value. I preserved this behavior, but added > a preference for a return value, if any, from the > script: again, on the basis that this seemed a (more) > natural behavior to me. DD, you said "not returning a > value is fine by you"... and that's what > <scriptcondition> always did, and _should_ still > allow... am _I_ missing anything (other than whatever > I've apparently done to break python compatibility)?
Ah, sorry, I meant that "not returning a value is meaningless to me". Sure, if a default value for the condition is set as an attribute, why not (although I don't see why that's necessary or useful), but a scriptcondition is supposed to be a script fragment which returns a boolean value, and I don't see the point of not returning a value. --DD PS: The error message could be nicer though ;-) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
