PEP 787: Safer subprocess usage using t-strings

[gerardw (Gerardwx)]

@steve.dower

The greater point is that my proposal is to allow either approach, while the counter-proposal is to force people into one particular format. I’d rather let people choose the style that works best for their case.

The proposal is to force the Documentation team to to expand the already bloated subprocess Documentation. As noted by CAM - Gelach in 2022

Take an example, the API reference for subprocess.run or subprocess.Popen. The former is over a full page, and the latter six pages of interleaved prose paragraphs, warnings, notes, “new/changed in”, “availability” and more, without much clear organization.

That’s not the fault of the Documentation writers, it’s an artifact of the historial development and expansions of subprocess. (universal_newlines and text? stdout=subprocess.PIPE and capture_output?)

The counter proposal to have pity on new Python developers trying to figure out subprocess by not adding additional complexity to an already overly complex module by not expanding the module with a brand new language feature that offers no benefits over the existing list implementation except aesthetics. (A manner of opinion).

If this is really important to the community deprecate the whole subprocess module and write a new module (e.g.) “launch” from scratch. lists or t-strings. No duplicate arguments, et. al.