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.