As a general rule, our documentation specifies what must be accepted, but doesn’t set an upper limit, since that’s how Python tends to operate.
For example, plenty of APIs will specify that they accept a list or a string, but will also accept other objects that look like those. Users may be “out of spec” when they use them like that, but we don’t see any reason to actively block them - we assume they know what they’re doing (often called the “we’re all consenting adults here” principle).
This means that occasionally we get stuck in a place where, when people make a fuss about the gap,[1] we either close it in one direction or the other. Sometimes, if we can draw the exact boundary and are confident it doesn’t have any negative impacts, we’ll update the documentation. Other times, we’ll add errors and break some users so that the complainers stop complaining. At a guess, this is in the first category, but it should definitely be raised in Core Development to get a proper consensus.
If the goal is to raise an error for an invalid template, the best way to do this is to instantiate the template. If you’ve got enough information to do it on construction, then go for it. Otherwise, rely on your users doing their testing, as they should, and they’ll find their own mistakes that way.
At some point, as a library author, you get to say “this uses Python’s string formatting and follows the same rules” without having to be responsible for reimplementing them.
Not saying you’re making a fuss this time, but sometimes people do demand that we change something… anything!
↩︎