Remember, 60% longer means 60% more typing when you create the code. Typically, my programs are about 30% I/O which means 60% longer format strings mean a lot more effort in coding.
I have a saying: If you're scared of typing, you shouldn't be a programmer. And how is it easier to have to consult the local printf documentation whenever you want to decipher your coworker's code? In most cases, my format strings merely contain {0}, {1}, {2}, and so on.
Besides, remember how much code is out there in C format strings. By creating a new standard you suddenly are putting all that outside easy conversion.
It's not new. C# had it years ago, and probably other languages before that. And do you really spend a lot of time converting printf statements into Python? That sounds like a royal pain with all of the type differences.
BTW, the old Python '%' format operator already supports positional formatting.
It's still around, for anyone who wants to keep writing inscrutable code to save keystrokes.
I think having a new text formatting library is OK, but it's an epic fail to deprecate something that has been working so well for so long. Why not keep the '%' operator while still having the 'format' string method? Are they so afraid of the Perl "there's more than one way to do it"?...
I expect they're afraid of Python programmers writing code that looks like Perl.
The "shell" argument is meant for security purposes. By setting shell=False one avoids script injection vulnerabilities.
You've completely ignored what I said, or failed to read the documentation. shell=True allows you to run full shell commands, including the piping you want to do. If you want to make it shorter, you can write a function:
def p(a):
subprocess.Popen(a, shell=True)
And then just tell anyone that reads your code that p() obviously stands for process. Or you can use s() for shell.
Or you can just stick to an older version of Python. No one's forcing you to upgrade.