Description formatting for pre-packaged constraints (example for #195)

[cgevans]

No description provided.

[dave-doty]

Ah, I see. But I think this may be sort of surprising behavior, so it might be best to also have a boolean parameter that shuts this off. Although even having the parameter True by default could be confusing: I could imagine someone getting very confused if they try to use curly braces in their string and get some strange error when format is called.

Maybe a good compromise is to put the format in a try/catch:

try:
  description = description.format(
    ...
  )
catch WhateverExceptionHappensWhenFormatGoesWrong:
  print('I tried parsing the description and it failed; to avoid this warning please set the parameter format_description to false, or avoid using curly braces {} in your description')

What do you think?

[cgevans]

That could make sense. Here's an attempt at it for this one case: the formatting should give either a KeyError (keyword not found, in which case the user may well have been trying to use the formatting) or ValueError (for parsing).

[dave-doty]

Do you want to leave this PR as a draft, or is it ready to merge?

[dave-doty]

Actually, some things should probably change, for example adding this feature to other functions that create constraints.

[cgevans]

Yes, this isn't done yet, I need to do the same thing elsewhere, and add some tests.

[dave-doty]

Yes, this isn't done yet, I need to do the same thing elsewhere, and add some tests.

Maybe merge the current dev into this branch. I've just added two new functions (described in #191 (comment)) that would also have their description fields altered. (Or in this case, descriptions)