This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mbussonn
Recipients gregory.p.smith, mbussonn, pablogsal, remi.lapeyre, rhettinger, serhiy.storchaka, steven.daprano
Date 2019-05-20.23:55:49
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1558396550.01.0.316041746334.issue36906@roundup.psfhosted.org>
In-reply-to
Content
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 ?
History
Date User Action Args
2019-05-20 23:55:50mbussonnsetrecipients: + mbussonn, rhettinger, gregory.p.smith, steven.daprano, serhiy.storchaka, pablogsal, remi.lapeyre
2019-05-20 23:55:50mbussonnsetmessageid: <1558396550.01.0.316041746334.issue36906@roundup.psfhosted.org>
2019-05-20 23:55:50mbussonnlinkissue36906 messages
2019-05-20 23:55:49mbussonncreate