Hi Nick and all other Python ideas friends,

yes, you are right. There is not much difference between PEP-501 or my
proposal.

One argument why I would like to prefer backticks:

Some IDEs detect that you want to use a f-string automatically:

You type:

name = 'Peter'
print('Hello {name...

and the IDE automatically adds the missing "f" in front of the string:

name = 'Peter'
print(f'Hello {name...

This is a handy feature (of PyCharm), which would not work reliably if
there are two different prefixes.

-------

You mentioned these things:

eager rendering: I think deferred rendering would increase the complexity a
lot. And I think it is not needed.

runtime value interpolation: It is up to the receiver of
types.InterpolationTemplate to handle the data structure.

dedicated templating libraries: One temp after the other. I think HTML and
SQL libraries would adapt as soon as the foundation
is available.

I would be happy if PEP-501 would come true.

Regards,
  Thomas Güttler

Am So., 27. Juni 2021 um 06:45 Uhr schrieb Nick Coghlan <ncogh...@gmail.com
>:

> Stephen J. Turnbull wrote:
> > But a
> > PEP 501 i-string "just works" nicely:
> > load_warning = i'Load is too high: {load}'
> >     while (theres_work_to_do_matey):
> >         if load > max_load:
> >             logging.warn(load_warning)
> > (This assumes a future version of logging.warn that calls str() on the
> > first argument if it is an InterpolationTemplate.)
>
> A "Why this rather than PEP 501's interpolation templates?" is the main
> thing I was looking for in the PEP and I didn't find it.
>
> If the proposal is just a variant on PEP 501 with the syntax changed from
> i"template" to \`template\` and the template type name changed from
> InterpolationTemplate to TemplateLiteral, it doesn't need to be a new PEP,
> I can just explicitly reject those spelling options in PEP 501. (The
> reasons for that PEP's deferral unfortunately still hold, though - eager
> rendering, runtime value interpolation, and dedicated templating libraries
> together cover enough cases that the motivation for introducing the
> semantic complexity of yet another templating option gets weakened
> dramatically).
>
> If the differences between the proposals run deeper than that, then the
> proposed new PEP needs to spell them out.
> _______________________________________________
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/XSGJO3VX3HBSGESRUFDTMI2LTJFNRY66/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/O6H6NLNJJDNUUDXREIURHVCXX4ZNBYAW/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to