> You could, of course, act on user input inside an f string, but the fault of that lies with the developer not sanitizing inputs, which is an issue with anything....

A good language protects the experienced developers from making a stupid mistake, and forbids the novices from them to trigger a learning response and guide them to better ways.

Example: In python if you use a normal map to implement an algorithm that depends on the elements being ordered in some way, then you will get different results for each run. If I remember correctly, I think python will randomize the order of the map every time it is iterated over. You see, developers could have got away with blaming the user for using an ordinary map when they should have used ordered map. But instead, they implementation map in such a way that it would be impossible to use it incorrectly.

> I think may be you gave the PHP example as how this mixing can lead to certain unintended issues (not necessarily in python with this PEP..

Yes. correct.

>it's just a convenience..

I come from a land filled with such 'conveniences'. it is called PHP. You can compare

    var_dump("228" == "0xe4");  -> True

See? a convenience. You can compare hex and decimal strings with out explicit conversion. And what is the result? Countless exploits and security holes that leverage things like these, all that can be possible blamed on the programmer. So was this worth it? Where would you draw the line? How much correctness are you willing to trade off for a minor convenience?

I may be over-reacting. But I think this pep is a step in the wrong direction and should be aggressively corrected.