Steven D'Aprano <steve+pyt...@pearwood.info> added the comment:
> 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.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue36906>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
