[Python-ideas] Draft2 PEP on string interpolation

[random832 at fastmail.us]

On Fri, Aug 28, 2015, at 03:52, Paul Moore wrote:
> On 28 August 2015 at 02:55,  <random832 at fastmail.us> wrote:
> > On Thu, Aug 27, 2015, at 13:27, Eric V. Smith wrote:
> >> The problem with this auto-rendering is that the format_spec and
> >> conversion character have to make sense to __format__. For example,
> >> you couldn't do this, if value were a string:
> >>
> >> to_html(e'<p>{value:raw}</p>')
> >
> > I feel like this would be better done with something like
> > {value!raw}.
>
> While I appreciate that people are still in a design phase with this,
> I'd like to point out that in the end, people will need to teach and
> remember this stuff.
>
> Currently ! introduces a conversion, which is one of r, s, or a (and
> is rarely used except for the occasional !r). Whereas : introduces a
> format spec, which is a mini-language for describing how to format the
> value and is specific to the type of the value.

Yes, but the format spec mini-language belongs to the type of the value.
Depending on what value is, "raw" could _already_ have a meaning.

> The "raw" thing above feels like neither of those things. It feels
> more like a conversion, but if so then conversions are currently
> single letters, and language-defined.

Well, at the time I posted that I thought we were moving away from
things being language-defined, because my mind was still on the "user-
defined string prefixes" proposal from a while back.

Them currently being single letters isn't really a compelling argument.

> I'd also expect (for that reason) that any conversions would be valid
> in any type of formatting (str.format, f-strings, e-strings,
> whatever).

And what if the type of value expects to be able to process a format
specifier of "raw", rather than it being used by to_html for its own
purpose? The advantage of conversion specifiers is that they're
currently a closed set.

----

One thing that I don't think *either* version successfully expresses is
that while in many cases (including the to_html example) we want a
string, that won't always be the case. If we have a syntax for
inserting something as, e.g., a SQL parameter, it should be able to
accept a double, but I'm not convinced it shouldn't _also_ be able to
describe putting the string result of converting the double with ".05d"
as a varchar.