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

Change by Jack Wong : -- nosy: +iforapsy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

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

Steven D'Aprano added the comment: This feature (or one very like it) has been requested again, this time with an "i" prefix: https://discuss.python.org/t/indented-multi-line-string-literals/9846/1 -- ___ Python tracker

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

Jan Tojnar added the comment: One benefit of using a compile time feature over a runtime method is that the former allows for more predictable dedenting by first dedenting and only then interpolating variables. For example, the following code does not dedent the test string at all:

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

Inada Naoki added the comment: > I don't think we need two algorithms here. I'm +1 to add str.dedent() which > mirroring only inspect.cleandoc(). I withdraw this. If we add str.dedent(), it must not be optimized for triple-quote literal. Auto dedenting is very nice to have. It can be

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

Serhiy Storchaka added the comment: Multiline string literals were added recently in Java (https://openjdk.java.net/jeps/378). The semantic is similar to Julia: autodedent and ignoring the first blank line. Multiline string literals have similar semantic in Swift

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

Inada Naoki added the comment: > (1) add a .dedent() method to str (and bytes?) - behaviors to consider > mirroring are textwrap.dedent() and inspect.cleandoc(). Given their utility > and similarities, it makes sense to offer both behaviors; behavior could be > selected by a kwarg passed

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

Gregory P. Smith added the comment: I expect several phases here: (1) add a .dedent() method to str (and bytes?) - behaviors to consider mirroring are textwrap.dedent() and inspect.cleandoc(). Given their utility and similarities, it makes sense to offer both behaviors; behavior could be

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

Steven D'Aprano added the comment: A string prefix would be a large language change that would need to go through Python-Ideas, a PEP and Steering Council approval. Let's not go there :-) A new string method is a comparatively small new feature that probably won't need a PEP or Steering

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

Terry J. Reedy added the comment: I read to the end of the patch and found astfold_dedent. A small point in favor of textwrap.dedent is immediately announcing that the string will be dedented. -- ___ Python tracker

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

Terry J. Reedy added the comment: I am opposed to more prefix characters. Are any string literal optimizations done now at compile time, like for 'abc'.upper? It does not exactly make sense to me to do just .dedent. But without the optimization, adding str.dedent without removing

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

Gregory P. Smith added the comment: (assigning to me as I want to help remi.lapeyre's .dedent() method PR move forward) -- assignee: -> gregory.p.smith ___ Python tracker

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

Change by Gregory P. Smith : -- versions: +Python 3.10 -Python 3.9 ___ Python tracker ___ ___ Python-bugs-list mailing list

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

Miguel Amaral added the comment: A related issue(which I believe has no topic in this forum yet) is substituting an expression that results in a multiline string into a multiline f-string while matching its indentation. If a new type of string prefix is made to auto-dedent, maybe the

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

Marco Sulla added the comment: When Python started to emulate the other languages? Who cares about what other languages do? Python uses `raise` instead of `throw`, even if `throw` is much more popular in the most used languages, only because `raise` in English has more sense. And IMHO a

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

Serhiy Storchaka added the comment: Julia syntax looks well thought out, so I suggest to borrow it. -- ___ Python tracker ___ ___

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

Serhiy Storchaka added the comment: The user expects what they read in the documentation of what they learn in other programming languages. If we update the documentation their expectation will change. As for other programming languages, Bash has an option for stripping all leading tab

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

Marco Sulla added the comment: Excuse me for the spam, but against make it the default behavior I have a simple consideration: what will expect a person that reads the code, that doesn't know Python? IMHO it expects that the string is *exactly* like it's written. The fact that it will be

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

Marco Sulla added the comment: Anyway there's something strange in string escaping and `inspect.cleandoc()`: >>> a = """ ... \nciao ... bello ... \ ciao ... """ >>> print(inspect.cleandoc(a)) ciao bello \ ciao >>> print("\ ciao") \ ciao I expected: >>> print(inspect.cleandoc(a))

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

Gregory P. Smith added the comment: .cleandoc is _probably_ more of what people want than .dedent? I hadn't bothered to even try to pick between the two yet. -- ___ Python tracker

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

Josh Rosenberg added the comment: Is there a reason folks are supporting a textwrap.dedent-like behavior over the generally cleaner inspect.cleandoc behavior? The main advantage to the latter being that it handles: '''First Second Third ''' just fine (removing the common

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

Marco Sulla added the comment: If I can say my two cents: 1. I preferred that the default behaviour of multi-line was to dedent. But breaking old code, even if for a little percentage of code, IMHO is never a good idea. Py2->Py3 should have proved it. 2. ``` remembers me too much the

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

Serhiy Storchaka added the comment: I think it would be better to use use backtick quotes for f-strings instead of the f prefix. This would stress the special nature of f-strings (they are not literals, but expressions). But there was strong opposition to using backticks anywhere in Python

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

Gregory P. Smith added the comment: Another option not using a new letter: A triple-backtick token. def foo(): value = ```this is a long multi line string i don't want indented. ``` A discuss thread was started so I reconnected it with this issue. See

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

Raymond Hettinger added the comment: We should consider dedicated syntax for compile-time dedenting: d"""\ This would be left aligned but this would only have four spaces And this would be left-justified. """ # Am not sure what to do about this last

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

Gregory P. Smith added the comment: I think dedenting docstring content by default would be a great thing to do. But that's a separate issue, it isn't quite the same as .dedent() due to the first line. I filed https://bugs.python.org/issue37102 to track that. --

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

Inada Naoki added the comment: Can we dedent docstring too? Is there any string like inspect.cleandoc(s) != inspect.cleandoc(s.dedent())? -- nosy: +inada.naoki ___ Python tracker

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

Matthias Bussonnier added the comment: > Oh, please, please, please PLEASE let's not over-sell this! Sorry didn't wanted to give you a heart attack. The optimisation has been mentioned, and you never know what people get excited on. > Such constant-folding ... Well, in here we might get

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

Steven D'Aprano 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

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

Matthias Bussonnier 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

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

Gregory P. Smith added the comment: Agreed, I'm in favor of going forward with this .dedent() optimization approach today. If we were to attempt a default indented multi-line str and bytes literal behavior change in the future (a much harder decision to make as it is a breaking change),

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

Steven D'Aprano added the comment: > While the string method works pretty well, I do not think this is the best > way. Regardless of what we do for literals, a dedent() method will help for non-literals, so I think that this feature should go in even if we intend to change the default

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

Serhiy Storchaka added the comment: While the string method works pretty well, I do not think this is the best way. If 98% of multiline string will need deindenting, it is better to do it by default. For those 2% that do not need deintentation, it can be prohibited by adding the backslash

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

Serhiy Storchaka added the comment: The optimization that can be done in the AST is done in the AST. -- ___ Python tracker ___ ___

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

Rémi Lapeyre added the comment: Thanks @serhiy.storchaka, it's far easier to do here. I pushed the patch to the attached PR. Is there a reason the other optimisations in the Peephole optimizer are not done in the AST? -- ___ Python tracker

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

Rémi Lapeyre added the comment: > Perform the optimization at the AST level, not in the peepholer. Thanks, this makes more sense. -- ___ Python tracker ___

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

Rémi Lapeyre added the comment: > Serhiy's message crossed with mine. And mine crossed with yours, sorry. I will update my PR shortly. -- ___ Python tracker ___

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

Steven D'Aprano added the comment: Serhiy's message crossed with mine -- you should probably listen to him over me :-) -- ___ Python tracker ___

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

Steven D'Aprano added the comment: > One issue with it is that in: > def f(): > return " foo".dedent() > f will have both " foo" and "foo" in its constants even if the first is not > used anymore. That seems to be what happens with other folded constants: py> def f(): ... return

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

Serhiy Storchaka added the comment: Perform the optimization at the AST level, not in the peepholer. -- nosy: +serhiy.storchaka ___ Python tracker ___

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

Rémi Lapeyre added the comment: Hi @steven.daprano, @gregory.p.smith. I added the first version of my PR for review. One issue with it is that in: def f(): return " foo".dedent() f will have both " foo" and "foo" in its constants even if the first is not used anymore. Removing it

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

Change by Rémi Lapeyre : -- keywords: +patch pull_requests: +13353 stage: -> patch review ___ Python tracker ___ ___

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

Gregory P. Smith added the comment: Thanks, it's actually good to see this being a feature accepted in other languages. -- priority: low -> normal ___ Python tracker ___

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

Steven D'Aprano added the comment: For the record, I just came across this proposed feature for Java: https://openjdk.java.net/jeps/8222530 Add text blocks to the Java language. A text block is a multi-line string literal that avoids the need for most escape sequences,

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

Change by Pablo Galindo Salgado : -- nosy: +pablogsal ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

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

Gregory P. Smith added the comment: I'd say go for it. We can't guarantee we'll accept the feature yet, but I think the .dedent() method with an optimization pass approach is worthwhile making a proof of concept of regardless. -- ___ Python

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

Rémi Lapeyre added the comment: Hi, I have been looking to get more acquainted with the peephole optimizer. Is it okay if I work on this? -- nosy: +remi.lapeyre ___ Python tracker

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

Gregory P. Smith added the comment: Oh good, I thought this had come up before. Your method idea that could be optimized on literals makes a lot of sense, and is notably more readable than yet another letter prefix. -- ___ Python tracker

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

Steven D'Aprano added the comment: +1 There's a long thread on something similar here: https://mail.python.org/pipermail/python-ideas/2018-March/049564.html Carrying over into the following month: https://mail.python.org/pipermail/python-ideas/2018-April/049582.html Here's an even older

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

Change by Matthias Bussonnier : -- nosy: +mbussonn ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

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

Raymond Hettinger added the comment: I agree that this is a recurring need and would be nice to have. -- nosy: +rhettinger ___ Python tracker ___

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

New submission from Gregory P. Smith : A Python pattern in code is to keep everything indented to look pretty while, yet when the triple quoted multiline string in question needs to not have leading whitespace, calling textwrap.dedent("""long multiline constant""") is a common pattern.