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
Interpolation
toReplacementField
? (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 thestring
module’s docs; and that the variable namefield
seems 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().args
toTemplate().segments
? (considering that the latter is more specific, and that it would help to establish this terminology element:segment
seems 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 aTemplate
from a template pattern specified as an ordinarystr
and 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.
-