Markdown code-block style syntax for string literals

Ideas
1

I think a Markdown code-block style syntax is pretty useful, with that, we can event highlight the multi-line str areas as code of some programming languages.

In this syntax, the word or sentence on the same line immediately after the beginning “```”, whose function is to identify the type or role of the string, will not be included in the resulting string.

2

The biggest downside to ``` as a string syntax, and reason I expect that never to be used within any programming language at this point: No code examples within a Markdown document would be able to contain triple-backtick tokens for strings. That’d be awkward.

I presume the reason Markdown chose to use triple-backticks it is that it was not used within any programming language. Markdown’s wide popularity in effect means it has become a Markdown only concept.

Otherwise while the idea is interesting, Python adopted the letter-prefix on quotes style (r"" b"" f"" universally across all four ", ', """, ''' styles) for string modifiers long ago. Choosing a new way of doing this would be inconsistent.

3 Likes
3

I’m not clear on exactly what the proposal is, but just as a point of reference, three tildes (~~~) are also accepted as code block delimiters.

4

It’s ok to change ``` to """, but a syntax that automatically dedent multi-line strings and ignore the words that follow on the same line as the beginning delimiter would be useful.

Example:

def query_students(name, age):
    code = fc"""SQL  # Pretend there's a comment here
    SELECT *
    FROM student
    WHERE name = "{name}"
      AND age = {age}
    """
    ...

Before doing a string formatting, the string literal above would be treated as "SELECT *\nFROM student\nWHERE name = \"{name}\"\n AND age = {age}\n".

5

This is interesting to me. I’ve long wondered why multi-line strings aren’t automatically dedented just like docstrings. “”" literals (especially f"“”) are widely useful, and universally awkward when they don’t have correct-looking indentation compared to the surrounding code.

6

For that, see the original Str.dedent vs str.removeindent - #34 for that (and links to other discussions and related feature requests).

7

This somehow relates with the recent idea of using annotations for common string formats and embedded language snippets (python/typing#1370, typing_extensions#55). That would allow to write the above example as

def query_students(name, age):
    code: Annotated[str, Language["sql"]] = f"""
    SELECT *
    FROM student
    WHERE name = "{name}"
      AND age = {age}
    """
    ...
8

Ah, this is my fault.

The OP of this thread was originally in that thread - I flagged it as off-topic, because I couldn’t make sense of it except that it seemed to be proposing something only vaguely related. But now I understand that it was intended as a different design for the same thing.

9

Well, it would be my fault too, of course. Should I merge it back in, then?

10

I don’t like this approach very much because it’s complicated for learner, and it doesn’t indicate that this is a string that the compiler will automatically unindent.

The main problem is that it is very difficult (and almost impossible) for editors (not IDEs, such as SublimeText, CodeMirror) or code highlighters (such as Prismjs) to support it.

I think it’s helpful to have a string syntax that automatically discards anything on the same line as the beginning delimiter, because the first line is special and bad for alignment, we can use it as a comment.