[Python-ideas] Draft PEP on string interpolation

[Paul Moore]

First of all, please accept my apologies for anything that's already
been explained that I've missed. This thread is huge and confusing,
and honestly I don't have the time to do much more than skim it. I'm
certainly commenting without doing all the research - I'm trying to
avoid gross errors, but how well I succeed I can't say.

On 25 August 2015 at 19:02, Mike Miller <python-ideas at mgmiller.net> wrote:
>
> On 08/25/2015 01:29 AM, Paul Moore wrote:
>>>
>>> Remember Nick Coghlan's statement that the "easy way should be the right
>>> way"? That's what this is trying to accomplish.
>>
>> But the right way is not to use os.system, so I don't *want* it to be
>
> Ok, a few hours before someone complained to Nick that he was using
> subprocess.call as an example when it didn't completely apply.  So I moved
> to the other alternative example that could be helped, os.system.  I have no
> particular love for it, and am not recommending it.  It was just one
> function out of many that needs input to be escaped as far as I was
> concerned.

I understand your point about "one function of many". Ignoring its
flaws for a moment, I understand that os.system is an easily
understood one of the many.

What I'm not clear about is whether under your proposal, os.system
would need to be *changed* to accept e-strings, or whether it would
work as it stands. Having just read through your PEP, I'm not sure I'm
any the wiser. I think what you're saying is that

x = 12
foo(e'number = {x}')

will be translated *at compile time* to

x = 12
foo(''.join(['number = ', str(x)]))

But that seems to leave no way for anything to "safely quote" x. And
there's no obvious way foo can influence the quoting if it *doesn't*
need rewriting to know about e-strings.

So you seem to be saying that e-strings will only be "safely quoted"
if the function using them knows to do so. Which leads back to the
question of how a user can *know* that an e-string will be safe or not
when used with a particular function.

That's not making the right way easy, it's giving function writers a
new way to make the right thing easy - but only if they target Python
versions with e-strings only, or they offer two options, one for
e-strings and one for old-style strings. That's likely to make it
*harder* for the end user to chose the safe option.

I'm sure I'm missing something fundamental in the above, because
that's so far away from offering the benefits you're suggesting. But I
can't work out what.

> I didn't forsee that that the function would be focused on to the point of
> the derailing the idea.  I suppose I'll try again if you'll bear with me.

Sorry. Maybe a better idea would be to show how someone would need to
write a safe os.system. If you're saying "you can just use os.system
unchanged from the current version", then see above - I don't
understand how.

>> If your e-string proposal works for this (via some consequence of
>> implicitly calling str()) then it may still be on the cards - but the
>> need for explicit str() calls in pathlib is a source of frustration
>
>
> In my original message (of this sub-thread) this is one of the main
> paragraphs:
>
>> To make it as simple as possible to use by end-developers, it 1) doesn't
>> require
>> str() to be run explicitly, it renders itself when needed via its various
>> methods and operators.  Look for .raw, if you need the original.

Please explain "renders itself". What "rendering" is done when it's
passed as an argument to a function (e.g. os.system)?

Put this another way, what is type(e'foo {x}')? If it's not str, then
at least some code (notably os.system in your example, as it wants
"safe quoting") using e-strings will need to know about them. If it
*is* str, then I'm baffled, as above.

> Also if you check the example script at the bitbucket url, you'll see it is
> the case, though I've not yet implemented every case.

Sorry, I couldn't work out what bitbucket URL you meant. If you meant
your PEP, there's a lot of code samples in there, but I'm not clear
which bit you mean :-(

Paul