[issue36906] Compile time textwrap.dedent() equivalent for str or bytes literals

[Matthias Bussonnier]

Matthias Bussonnier <bussonniermatthias at gmail.com> added the comment:

I've tried a bit PR 13455, I find this way nicer than textwrap.dedent(...), 
though I wonder if f-string readability (and expected behavior?) might suffer a tiny bit with the order of formatting the f-string vs dedenting. 

In the following it is clear that dedent is after formatting: 

>>> dedent(f"   {stuff}")

It might be unclear for the following especially if `.dedent()` get sold as zero-overhead at compile time.

>>> f"   {stuff}".dedent()

Could it be made clearer with the peephole optimiser (and tested, I don't believe it is now), that dedent applies after-formatting ?

Alternative modifications/suggestions/notes: 

   - I can also see how having dedent applied  **before** formatting with f-string could be useful or less surprising ( a d"" prefix could do that... just wondering what your actual goal is). 
   - Is this a supposed to deprecating textwrap.dedent ? Duck-typing and stuff, could textwrap.dedent work on non-str things and the current implementation not ( it assumes the `.dedent()` method exists) and thus be backward-incompatible ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36906>
_______________________________________