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. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
