Skip to content

PEP 822: add a Rejected Idea #4795

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
methane wants to merge 1 commit into
base: main
Choose a base branch
from
Open

PEP 822: add a Rejected Idea #4795

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
37 changes: 36 additions & 1 deletion peps/pep-0822.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -334,9 +334,12 @@ triple quote, it removes indent from text too.
Ruby also has `"squiggly" heredoc <https://ruby-doc.org/core-2.5.0/doc/syntax/literals_rdoc.html#label-Here+Documents>`__
that removes indent from lines in heredoc.

Perl has `"Indented Here-documents <https://perldoc.perl.org/perl5260delta#Indented-Here-documents>`__
since Perl 5.26 too.

Java, Julia, and Ruby uses the least-indented line to determine the amount of
indentation to be removed.
Swift, C#, and PHP uses the indentation of the closing triple quotes or
Swift, C#, PHP, and Perl uses the indentation of the closing triple quotes or
closing marker.


Expand Down Expand Up @@ -469,6 +472,38 @@ quotes, these workarounds are not necessary when rewriting ``textwrap.dedent()``
to d-strings.


Allow content after opening quotes
----------------------------------

There was also a proposal to allow writing content immediately after
the opening quotes, just like existing ``"""``.

Since closing quotes can be on the same line as content, it looks symmetrical
to allow content right after opening quotes too.
And it would make it easier to rewrite existing ``"""`` to d-strings.

On the other hand, it increase the number of syntax rules that readers need to
remember in order to understand how much indentation will be removed.

Also, allowing content after opening quotes would not resolve the usability
issue where existing ``textwrap.dedent("""...""")`` users must write
``"""\<newline>`` to avoid including the first newline.
Julia avoids this issue by removing the first newline when starting with
``"""<newline>``, but this adds another syntax rule that users need to remember.

Since we rejected the idea of using ``__future__ import``, we prioritized
ease of use for users rewriting from ``textwrap.dedent()`` or those who
wanted to use ``textwrap.dedent()`` but couldn't for some reason, over
the ease of rewriting existing multiline string literal users to d-strings.

Additionally, `in past discussions <https://discuss.python.org/t/90988>`__,
there was a proposal to allow writing hints or comments for syntax highlighting
immediately after the opening quote.
That proposal was rejected to move the d-string discussion forward, but by not
allowing anything right after the opening quote, it leaves room for possibly
allowing comments there in the future.


Copyright
=========

Expand Down
Loading