Steven D'Aprano <steve+pyt...@pearwood.info> added the comment:
For the record, I just came across this proposed feature for Java: https://openjdk.java.net/jeps/8222530 Add text blocks to the Java language. A text block is a multi-line string literal that avoids the need for most escape sequences, automatically formats the string in predictable ways, and gives the developer control over format when desired. It seems to be similar to Python triple-quoted strings except that the compiler automatically dedents the string using a "re-indentation algorithm". (Which sounds to me similar to, if not identical, to that used by textwrap.) The JEP proposal says: A study of Google's large internal repository of Java source code showed that 98% of string literals, once converted to text blocks and formatted appropriately, would require removal of incidental white space. If Java introduced multi-line string solution without support for automatically removing incidental white space, then many developers would write a method to remove it themselves and/or lobby for the String class to include a removal method. which matches my own experience: *most* but not all of my indented triple-quotes strings start with incidental whitespace that I don't care about. But not quite all, so I think backwards compatibility requires that *by default* triple-quoted strings are not dedented. Note that there are a couple of major difference between the JEP proposal and this: - The JEP proposes to automatically dedent triple-quoted strings; this proposal requires an explicit call to .dedent(). - The JEP proposal allows the user to control the dedent by indenting, or not, the trailing end-quote; - however that means that in Java you won't be able to control the dedent if the string doesn't end with a final blank line; - Should the dedent method accept an optional int argument specifying the number of spaces to dedent by? (Defaulting to None, meaning "dedent by the common indent".) If so, that won't affect the compile-time optimization so long as the argument is a literal. - the JEP performs the dedent before backslash escapes are interpreted; in this proposal backslash escapes will occur before the dedent. The JEP also mentions considering multi-line string literals as Swift and Rust do them: https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md https://stackoverflow.com/questions/29483365/what-is-the-syntax-for-a-multiline-string-literal I mention these for completeness, not to suggest them as alternatives. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue36906> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
