# PEP 787: Safer subprocess usage using t-strings **URL:** \ **Category:** PEPs\ **Created:** [April 14, 2025, 3:25pm UTC](https://discuss.python.org/t/pep-787-safer-subprocess-usage-using-t-strings/88311 "2025-04-14T15:25:18Z")\ **Posts on this page:** 1\ **Showing post:** 65
**Author:** ![blhsing](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/blhsing/32/25812_2.png) [@blhsing](https://discuss.python.org/u/blhsing)\ **Post date:** [April 23, 2025, 7:25am UTC](https://discuss.python.org/t/pep-787-safer-subprocess-usage-using-t-strings/88311/65 "2025-04-23T07:25:31Z")
> [@pitrou](#): > > That’s certainly a matter of perception. Personally I’d rather read a list of arguments, because I know that there will be no splitting issues if some arguments have whitespace or other special characters in them. > > Given that t-strings don’t seem like they would be able to eliminate all issues with splitting, I’m not sure I would like to read them in that context. True. A t-string can’t unambiguously split `t"echo 'Hello, World!'"` across platforms even with `shell=False` unless we document the splitting to always follow the shlex/bash logics, which may be counter-intuitive to some Windows users unfortunately. In many real-world use cases where spaces and special characters are not part of the literal arguments of a command line though, I think t-string can still be a more readable option, and we may just have to document the limitations like we already do for `shell=True` in the [Security Considerations](https://docs.python.org/3/library/subprocess.html#security-considerations) section. > [@](#): > > Also, as I pointed above, it’s easy to misread a leading “f” as a “t” or the reverse. This sounds like an argument against [PEP750: Template Strings (new updates)](https://discuss.python.org/t/pep750-template-strings-new-updates/71594/1) rather than this proposal though. --- _[View the full topic](https://discuss.python.org/t/pep-787-safer-subprocess-usage-using-t-strings/88311)._