Add Template(strings=..., interpolations=...) API

[da-woods]

Feature or enhancement

Proposal:

Internally, you store strings and interpolations as separate attributes. However the constructor to Template requires them to be passed as a long tuple of positional arguments (which then gets manually separated out).

For the likely Cython implementation it (probably) also makes sense to generate the strings and templates separately. For CPython modules it's possible to get _PyTemplate_Build out of the internal headers and use that. However that doesn't help for the Limited API.

In this case we have to go go through the Python constructor of Template - that's reasonable except that we have to do a lot of work zipping strings and interpolations into a single tuple so that the constructor of Template can then undo all the work putting them back.

It would be useful to have an interface to construct a Template from two iterables of strings and interpolations. I'd be happy with this being a Python API (rather than a C API). My initial proposal would be to define Template.__new__ as Template.__new__(cls, *args, strings=None, interpolations=None) and make it an error to pass both args and the keyword arguments in the same call.

Obviously there's multiple ways to implement Template and in future you might prefer not to separate the two. In this case the API I'm proposing would still work but no longer be the most efficient way to build it - I don't think this is a problem.

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

No response

[sobolevn]

Genuine question: do we really need two similar and incompatible APIs to do the same thing?

[da-woods]

Genuine question: do we really need two similar and incompatible APIs to do the same thing?

I'm proposing it because it would be more efficient with the current structure of Template. It isn't "needed" in the sense that it doesn't allow you to do anything new that you can't currently do.

But yes I agree there is a cost to maintaining multiple interfaces and maybe this doesn't justify the cost.

[picnixz]

I'm proposing it because it would be more efficient with the current structure of Template

How "more efficient" would it be? I don't think users care about the cost of explicitly instantiating templates. Also, strings=..., interpolations=... means that we don't have the possible collapse feature. And I am unsure to what this new interface would be equivalent to:

• is it Template(*strings, *interpolations)? if so, I don't think it's useful
• is it something else? if so, I'm -1 because it's too much assumptions and the addressed use cases are not that many.

For instance:

>>> template = Template(
    'Ah! We do have ', Interpolation(cheese, 'cheese'), '.'
)
>>> list(template)
['Ah! We do have ', Interpolation('Camembert', 'cheese', None, ''), '.']

The latter would not be convertible into the new format:

>>> strings = ('Ah! We do have', '.')
>>> interpolations = [Interpolation(cheese, 'cheese')]
>>> template = Template(strings=string, interpolations=interpolations)
>>> list(template)  # ???

[da-woods]

It would be equivalent to _PyTemplate_Build with some validation. So it would be equivalent to Template(strings[0], interpolations[0], string[1], interpolations[1], ..., strings[n], interpolations[n], strings[n+1]).

So yes - it would have to be more restrictive than the regular constructor. len(strings) would need to equal len(interpolations)+1.

I don't think users care about the cost of explicitly instantiating templates.

My assumption is that most templates are instantiated once and then iterated once. So the performance of them is just the sum of those two things. Maybe that's a wrong assumption?

However my use-case is mostly to let Cython (and maybe other code-generators) instantiate them explicitly rather than users. I can work without it, but not efficiently.

[picnixz]

I don't think interleaving is that common. As soon as someone wants to insert or remove an additional string, it breaks the entire construction. The reader also needs to exactly know that strings[0] will be put before interpolations[0] and that strings[1] immediately follows. The mental model for that is harder IMO and not worth the cost. Instead, I suggest using the following helper (generalized by more_itertools.interleave):

def special_interleave(strings, interpolations):
    strings = tuple(strings)
    interpolations = tuple(interpolations)
    if len(strings) != len(interpolations) + 1:
        raise ValueError
    yield from chain.from_iterable(zip(strings, interpolations))
    yield strings[-1]

[picnixz]

My assumption is that most templates are instantiated once and then iterated once. So the performance of them is just the sum of those two things. Maybe that's a wrong assumption?

Instantiation is performed once, but it's not necessarily the case that the template will only be used once.

[picnixz]

@davepeck I think this a suggestion you want to add to your list of desired features (I'm not implying that it should be accepted). I'm however going to close this specific issue instead as (1) it could be too niche (2) I don't really like the proposed API (it's too confusing to do the interleaving implicitly I think; I'd prefer that someone uses an explicit interleave function here and it would really only work when we have exactly n+1 string and n interpolations which is a niche case).