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 steven.daprano
Recipients gregory.p.smith, mbussonn, pablogsal, remi.lapeyre, rhettinger, serhiy.storchaka, steven.daprano
Date 2019-05-21.01:05:18
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <20190521010509.GI4221@ando.pearwood.info>
In-reply-to <1558396550.01.0.316041746334.issue36906@roundup.psfhosted.org>
Content
> It might be unclear for the following especially if `.dedent()` get 
> sold as zero-overhead at compile time.

Oh, please, please, please PLEASE let's not over-sell this! There is no 
promise that dedent will be zero-overhead: it is a method, like any 
other method, which is called at runtime. Some implementations *might* 
*sometimes* be able to optimize that at compile-time, just as some 
implementations *might* *sometimes* be able to optimize away long 
complex arithmetic expressions and do them at compile time.

Such constant-folding optimizations can only occur with literals, since 
arbitrary expressions aren't known at compile-time. F-strings aren't 
string literals, they are executable code and can run thngs like this:

f"{'abc' if random.random() > 0.5 else 'xyz'}"

So we don't know how many spaces each line begins with until after the 
f-string is evaluated:

f"""{m:5d}
{n:5d}"""

Unless we over-sell the keyhole optimization part, there shouldn't be 
anything more confusing about dedent than this:

x, X = 'spam', 'eggs'
f"{x}".upper()
# returns 'SPAM' not 'eggs'

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

We should certainly make that clear that 

Personally, I think we should soft-sell on the compile-time optimization 
until such time that the Steering Council decides it should be a 
mandatory language feature.

> 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).

I don't see how it will make any difference in the common case. And the 
idea here is to avoid yet another string prefix.

>    - Is this a supposed to deprecating textwrap.dedent ? 

I don't think so, but eventually it might.
History
Date User Action Args
2019-05-21 01:05:19steven.dapranosetrecipients: + steven.daprano, rhettinger, gregory.p.smith, serhiy.storchaka, mbussonn, pablogsal, remi.lapeyre
2019-05-21 01:05:19steven.dapranolinkissue36906 messages
2019-05-21 01:05:18steven.dapranocreate