One more thing… Given that certain details of the [Static]Template’s interface need to be decided now (that is, in PEP 750), and that, once they are decided, they’ll be carved in stone (at least to much extent) – I’d like to ask you to consider whether it wouldn’t be a good idea to:
-
(1) …rename
InterpolationtoReplacementField? (considering that, as it has already been noted in an earlier post, replacement field is a well established term – used in the f-strings syntax docs and the relevant portions of thestringmodule’s docs; and that the variable namefieldseems to feel natural, when referring to instances of that type – see several code snippets in the posts in this thread, even not counting those written by me
) -
(2) …rename
Template().argstoTemplate().segments? (considering that the latter is more specific, and that it would help to establish this terminology element:segmentseems quite accurate to refer to any of thosestr-or-replacement-field components we deal with; and it has also been used in this thread as a variable name in several code snippets by Alyssa) -
(3) …“move” the current
Template()constructor’s low-level signature+semantics to a classmethod:Template.from_segments(), and make theTemplate()constructor itself have more high-level signature+semantics? Namely, to allow users to create aTemplatefrom a template pattern specified as an ordinarystrand a mapping from replacement field names to their expression values. Thanks to that:-
a counterpart to
str.format()/format_map(), for which (among others) @pf_moore asked, would be exposed to the user in an articulate manner; -
a handy building block for future “true templating” tools would be provided (EDIT: and that would help reduce the terminological dissonance I referred to in an earlier post);
-
the crux of an important underlying procedure (of turning a template pattern and data to an actual
Template) would be exposed.
-