Allow inclusion of other arguments in description for constraints.

[cgevans]

Currently, the description in most constraints is optional. If unset, a default is set that includes the threshold argument via an f-string. However, when not using the default, you can't make use of the constraint arguments in the description the way the default does.

I think it might be better to instead use, eg, description = description.format(threshold=threshold, short_description=short_description, temperature=temperature, ...) in the constraint. This would (a) allow the default description to actually be included as the argument default rather than None (and allow the type of description to be str instead of Optional[str], and also allow the user to set a description that includes other arguments without needing to keep track of them per-constraint, by using "{argument}" outside an f-string.

(For example, I'd like to have a description that includes threshold and short_description.)

[cgevans]

(I'd be happy to implement this if it seems like a good idea.)

[dave-doty]

It sounds a bit like you want to do something like a generalized "description schema" that depends on various common parameters such as threshold and temperature in a uniform way? Of course you can always just set the description field to whatever you want when calling a pre-packaged constraint function, e.g.,

threshold = -4.0
temperature = 50.0
constraint = nc.rna_duplex_strand_pairs_constraint(
  description=f'RNAduplex energy at least {threshold} at {temperature} C')

But I assume the issue is that you have some uniform way of handling this for all constraints that use parameters such as threshold, temperature, etc., and you want to only write the function once that turns those parameters into a description?

Maybe I'm not understanding properly. Do you have a short example of how code using this feature would look?

[cgevans]

Of course you can always just set the description field to whatever you want when calling a pre-packaged constraint function, e.g.,

Yes, that's what I'm doing now. This would just make things a bit less redundant for me, and a bit less error-prone when dealing with many constraints (here, using the same constraint with different thresholds for strand pairs of different strand groups and number of complementary domains).

But I assume the issue is that you have some uniform way of handling this for all constraints that use parameters such as threshold, temperature, etc., and you want to only write the function once that turns those parameters into a description?

Pretty much, yes. The initial motivation is that I wanted to do what the pre-packaged constraint was doing with the description (adding the threshold automatically).

Maybe I'm not understanding properly. Do you have a short example of how code using this feature would look?

It might be easier to show an example of how it would be implemented. I've made a draft pull request that shows this for one pre-packaged constraint (rna_duplex_strand_pairs_constraint). The idea is that rather than using an f-string in the functions, description is set with a .format() call including all the string/numeric parameters. Then the following will work, without threshold, temperature, or short_description being variables:

nc.rna_duplex_strand_pairs_constraint(
  description='RNAduplex energy at least {threshold} at {temperature} C ({short_description})')

(note the lack of the f)

This also means that the user can see what the default description is as the default argument to the function. If the user uses an f-string (as in your example), nothing will change; if they wanted to combine both, they'd need to use something like {{threshold}} in the f-string.

This is similar to what logging in the standard library does for log messages, but despite the Python documentation recommending against printf-style formatting, that is all that logging supports.