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 <[email protected]
>:
> 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 -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/XSGJO3VX3HBSGESRUFDTMI2LTJFNRY66/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/O6H6NLNJJDNUUDXREIURHVCXX4ZNBYAW/
Code of Conduct: http://python.org/psf/codeofconduct/
