[Python-ideas] Draft PEP on string interpolation

[Paul Moore]

On 24 August 2015 at 23:04, Mike Miller <python-dev at mgmiller.net> wrote:
> On 08/24/2015 02:54 PM, Paul Moore wrote:
>>
>> Agreed. In a convenience library where it's absolutely clear that a
>> shell is involved (something like sarge or invoke) this is OK, but not
>> in the stdlib as the "official" way to call external programs.
>
> Hmm, don't focus on os.system(), it could be any function, and not
> particularly relevant, nor do I recommend this line as the official way.

Well, can you use an example that isn't misleading in its security
implications? Specifically, I assumed from your use of os.system that
you were proposing that the stdlib function (specifically in this
case, a function that we've been trying to deprecate in favour of more
secure alternatives for years) be updated to understand e-strings.

> 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
easy. If you have a better example than running shell commands, please
explain. (If your example is running full-blown shell syntax, rather
than single commands, please give a more complicated example and we
can let the debate explode into one about portability of shell
constructs - but os.system to run a single command with a set of
arguments is *wrong* and subprocess.Popen was created to replace it
with a cross-platform, secure by default, solution).

>> - People will fail to understand the difference between e'...' and
>> f'...' and will use the wrong one when using os.system, and things
>> will work correctly but with security vulnerabilities.
>
>
> I don't recommend e'' and f'', only e'' at this moment.

Then I'm strongly against this. As I've stated on a number of
occasions, to me the crucial main use of any variation on this
proposal is

    print(f"Iteration {n}: Duration {end-start}")

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
there, so I'd like to be 100% sure that your proposal doesn't result
in a need for explicit str() calls anywhere before accepting that
e-strings can replace f-strings.

By the way, the terminology in this thread (e-strings, f-strings,
i-strings...) is dreadful. We need names that capture the essential
differences (I've already proposed "format strings" for f-strings).
Naming is important!

Paul