Reacting to:
No, I cannot. I just thought of a way to keep users from using "shell=True". I *think* they do it after they experience that "del" for instance is not found. They conclude "ah, I need the shell", which is not true.
Even putting aside the fact this is pure conjecture, the kind of people who make decisions like this will find a zillion more ways to shoot themselves in the foot. They don't need a cleaner syntax, they need to learn the basics of programming in a high-level language to understand how it's different from programming in the shell. In particular, why spawning a subprocess for something covered by a library function is a bad idea.
So whatever you come up with, the effect should be that people no longer use the shell. THATs what I want, after bad experience with non-escaped "^" in a regex, that caused some really weird result.
How about starting off with marking all use of "shell=True" as deprecated and then replacing the parameter with "risky_shell=True" or having no such parameter and adding "risky_" or "dangerous_" wrappers for all items that currently have the "shell=True" option. This would at least highlight that the developer is performing a risky operation, to me a part of the problem is that "shell=True" sounds innocuous so it is rarely picked up as a potential problem. I do quite like the idea of having a "with_path=True|False" option or maybe a "use_path=" that defaults to sys.path for all of the subprocess functions that would allow a little more control over the execution environment. -- Steve (Gadget) Barnes Any opinions in this message are my personal opinions and do not reflect those of my employer.