I can currently write: from textwrap import dedent as d print(d(""" I am A Line """)) It doesn't feel like these hypothetical d-strings are with new syntax. On Sat, Mar 31, 2018, 11:49 AM Robert Vanden Eynde wrote:

So yes, currently you just do :

import textwrap

print(textwrap.dedent(""" I am A Line """))

So you'd want a string litteral ?

print(d""" I am A Line """)

Le sam. 31 mars 2018 à 17:06, Ryan Gonzalez a écrit :

...

I have to admit, regardless of how practical this is, it would surely get rid of a ton of textwrap.dedent calls all over the place...

On March 31, 2018 9:50:43 AM Marius Räsener wrote:

...

Hey List,

this is my very first approach to suggest a Python improvement I'd think worth discussing.

At some point, maybe with Dart 2.0 or a little earlier, Dart is now supporting multiline strings with "proper" identation (tried, but I can't find the according docs at the moment. probably due to the rather large changes related to dart 2.0 and outdated docs.)

What I have in mind is probably best described with an Example:

print(""" I am a multiline String. """)

the closing quote defines the "margin indentation" - so in this example all lines would get reduces by their leading 4 spaces, resulting in a "clean" and unintended string.

anyways, if dart or not, doesn't matter - I like the Idea and I think python3.x could benefit from it. If that's possible at all :)

I could also imagine that this "indentation cleanup" only is applied if the last quotes are on their own line? Might be too complicated though, I can't estimated or understand this...

thx for reading, Marius

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

-- Ryan (ライアン) Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else https://refi64.com/

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

It would radically change the meaning of every existing multi-line string. That is an enormous backwards-compatibility break. It might work as a __future__ import, though. On Sat, Mar 31, 2018, 13:03 Marius Räsener wrote:

Hey David,

hm, that's actually a nice way to solve this too I guess, besides the additional import and "string literal".

but as I answered to robert before (did it wrong with who to answer, correct it just now so the mailing-list has the answer, too) was, that I don't have a string literal in mind for this.

Like I don't see a reason why this couldn't be the default thing for all string literals?

again, the Idea is just to use the closing quotes to determine the indentation length ...

2018-03-31 18:51 GMT+02:00 David Mertz :

...

I can currently write:

from textwrap import dedent as d print(d(""" I am A Line """))

It doesn't feel like these hypothetical d-strings are with new syntax.

On Sat, Mar 31, 2018, 11:49 AM Robert Vanden Eynde wrote:

...

So yes, currently you just do :

import textwrap

print(textwrap.dedent(""" I am A Line """))

So you'd want a string litteral ?

print(d""" I am A Line """)

Le sam. 31 mars 2018 à 17:06, Ryan Gonzalez a écrit :

...

I have to admit, regardless of how practical this is, it would surely get rid of a ton of textwrap.dedent calls all over the place...

On March 31, 2018 9:50:43 AM Marius Räsener wrote:

...

Hey List,

this is my very first approach to suggest a Python improvement I'd think worth discussing.

At some point, maybe with Dart 2.0 or a little earlier, Dart is now supporting multiline strings with "proper" identation (tried, but I can't find the according docs at the moment. probably due to the rather large changes related to dart 2.0 and outdated docs.)

What I have in mind is probably best described with an Example:

print(""" I am a multiline String. """)

the closing quote defines the "margin indentation" - so in this example all lines would get reduces by their leading 4 spaces, resulting in a "clean" and unintended string.

anyways, if dart or not, doesn't matter - I like the Idea and I think python3.x could benefit from it. If that's possible at all :)

I could also imagine that this "indentation cleanup" only is applied if the last quotes are on their own line? Might be too complicated though, I can't estimated or understand this...

thx for reading, Marius

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

-- Ryan (ライアン) Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else https://refi64.com/

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

On 3/31/2018 2:14 PM, Marius Räsener wrote:

Oh, ok... yeah didn‘t think of that. Except I guess I‘d assume that so far multiline strings are either with textwrap or ‚don‘t care‘? Maybe?

For docstrings, I don't care, as a docstring consumer like help() can reformat the docstring with indents and dedents. For instance

...

...

def f(): def g(): """returnx

more doc """ print( g.__doc__) help(g)

...

...

f() returnx

more doc Help on function g in module __main__: g() returnx more doc For other situations, parse-time string concatenation often suffices, as I showed in my response to the original post. This example from idlelib.config shows the increased flexibility it allows. It has 1-line padding above and 1-space padding to the left to look better when displayed in a popup box. warning = ('\n Warning: config.py - IdleConf.GetOption -\n' ' problem retrieving configuration option %r\n' ' from section %r.\n' ' returning default value: %r' % (option, section, default)) With no padding, I would not argue with someone who prefers textwrap.dedent, but dedent cannot add the leading space. For literals with really long lines, where the physical indent would push line lengths over 80, I remove physical indents. class TestClass(unittest.TestCase): \ test_outputter(self): expected = '''\ First line of a really, really, ............................, long line. Short line. Summary line that utilizes most of the room alloted, with no waste. ''' self.assertEqual(outputter('test'), expected) -- Terry Jan Reedy

Hey Robert Not really, I don‘t think another string literal would be nice. Also, to correct your example, it would have to look something like: print(d“““ I am a Line “““) The Idea is to use the closing quotes to detect the indentation length so to speak... 2018-03-31 17:48 GMT+02:00 Robert Vanden Eynde :

So yes, currently you just do :

import textwrap

print(textwrap.dedent(""" I am A Line """))

So you'd want a string litteral ?

print(d""" I am A Line """)

Le sam. 31 mars 2018 à 17:06, Ryan Gonzalez a écrit :

...

I have to admit, regardless of how practical this is, it would surely get rid of a ton of textwrap.dedent calls all over the place...

On March 31, 2018 9:50:43 AM Marius Räsener wrote:

...

Hey List,

this is my very first approach to suggest a Python improvement I'd think worth discussing.

At some point, maybe with Dart 2.0 or a little earlier, Dart is now supporting multiline strings with "proper" identation (tried, but I can't find the according docs at the moment. probably due to the rather large changes related to dart 2.0 and outdated docs.)

What I have in mind is probably best described with an Example:

print(""" I am a multiline String. """)

the closing quote defines the "margin indentation" - so in this example all lines would get reduces by their leading 4 spaces, resulting in a "clean" and unintended string.

anyways, if dart or not, doesn't matter - I like the Idea and I think python3.x could benefit from it. If that's possible at all :)

I could also imagine that this "indentation cleanup" only is applied if the last quotes are on their own line? Might be too complicated though, I can't estimated or understand this...

thx for reading, Marius

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

-- Ryan (ライアン) Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else https://refi64.com/

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

In 3.6, we introduced a new prefix, 'f', so there was no back compatibility issue.  There was, however, a combinatorial explosion issue, as 'F' was also added (a mistake, I now think), and no order requirement (possibly another mistake).  Hence

stringprefix    ::=  "r" | "u" | "R" | "U"

grew to

stringprefix    ::=  "r" | "u" | "R" | "U" | "f" | "F"                      | "fr" | "Fr" | "fR" | "FR" | "rf" | "rF" | "Rf" | "RF"

New unordered 'd' and 'D' prefixes, for 'dedent', applied to multiline strings only, would multiply the number of alternatives by about 5 and would require another rewrite of all code (Python or not) that parses Python code (such as in syntax colorizers).

I think you're exaggerating the difficulty somewhat.  Multiplying the number of alternatives by 5 is not the same thing as increasing the complexity of code to parse it by 5. A new string prefix, 'd' say, would seem to be the best way of meeting the OP's requirement. That said, I'm about +0 on such a proposal, given that there are already reasonable ways of doing it. Regards Rob Cliffe

Ok I see this is nothing for any 3.x release. I imagine this now either ‚clean‘ for users with compatibility break or just leave things as they are. So, if at all, maybe something for Python 4 :) Coincidence I watched yesterday Armin Ronachers talk related to seeing compatibility as the holy cow - interesting watch... https://www.youtube.com/watch?v=xkcNoqHgNs8&feature=youtu.be&t=2890 Steven D'Aprano schrieb am So. 1. Apr. 2018 um 03:49:

On Sun, Apr 01, 2018 at 02:20:16AM +0100, Rob Cliffe via Python-ideas wrote:

...

...

New unordered 'd' and 'D' prefixes, for 'dedent', applied to multiline strings only, would multiply the number of alternatives by about 5 and would require another rewrite of all code (Python or not) that parses Python code (such as in syntax colorizers).

I think you're exaggerating the difficulty somewhat. Multiplying the number of alternatives by 5 is not the same thing as increasing the complexity of code to parse it by 5.

Terry didn't say that it would increase the complexity of the code by a factor of five. He said it would multiply the number of alternatives by "about 5". There would be a significant increase in the complexity of the code too, but I wouldn't want to guess how much.

Starting with r and f prefixes, in both upper and lower case, we have:

4 single letter prefixes (plus 2 more, u and U, that don't combine with others) 8 double letter prefixes

making 14 in total. Adding one more prefix, d|D, increases it to:

6 single letter prefixes (plus 2 more, u and U) 24 double letter prefixes 48 triple letter prefixes

making 80 prefixes in total. Terry actually underestimated the explosion in prefixes: it is closer to six times more than five (but who is counting? apart from me *wink*)

[Aside: if we add a fourth, the total becomes 634 prefixes.]

-- Steve _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

On 3/31/2018 9:48 PM, Steven D'Aprano wrote:

On Sun, Apr 01, 2018 at 02:20:16AM +0100, Rob Cliffe via Python-ideas wrote:

...

...

New unordered 'd' and 'D' prefixes, for 'dedent', applied to multiline strings only, would multiply the number of alternatives by about 5 and would require another rewrite of all code (Python or not) that parses Python code (such as in syntax colorizers).

I think you're exaggerating the difficulty somewhat.  Multiplying the number of alternatives by 5 is not the same thing as increasing the complexity of code to parse it by 5.

Terry didn't say that it would increase the complexity of the code by a factor of five. He said it would multiply the number of alternatives by "about 5". There would be a significant increase in the complexity of the code too, but I wouldn't want to guess how much.

Starting with r and f prefixes, in both upper and lower case, we have:

4 single letter prefixes (plus 2 more, u and U, that don't combine with others) 8 double letter prefixes

making 14 in total. Adding one more prefix, d|D, increases it to:

6 single letter prefixes (plus 2 more, u and U) 24 double letter prefixes 48 triple letter prefixes

making 80 prefixes in total. Terry actually underestimated the explosion in prefixes: it is closer to six times more than five (but who is counting? apart from me *wink*)

[Aside: if we add a fourth, the total becomes 634 prefixes.]

Not that it really matters, but there's some code I use whenever I feel like playing with adding string prefixes. It usually encourages me to not do that! Lib/tokenize.py:_all_string_prefixes exists just for calculating string prefixes. Since it's not what is actually used by the tokenizer, I don't claim it's perfect (but I don't know of any errors in it). According to it, and ignoring the empty string, there are currently 24 prefixes: {'B', 'BR', 'Br', 'F', 'FR', 'Fr', 'R', 'RB', 'RF', 'Rb', 'Rf', 'U', 'b', 'bR', 'br', 'f', 'fR', 'fr', 'r', 'rB', 'rF', 'rb', 'rf', 'u'} And if you add 'd', and it can't combine with 'b' or 'u', I count 90: {'rdf', 'FR', 'dRF', 'rD', 'FrD', 'DFr', 'frd', 'RDf', 'u', 'DF', 'd', 'Frd', 'frD', 'dFr', 'rDF', 'fD', 'rB', 'dFR', 'FD', 'dr', 'Fr', 'DfR', 'fdR', 'Rb', 'dfr', 'rdF', 'rf', 'Drf', 'R', 'RB', 'BR', 'FdR', 'bR', 'DFR', 'RdF', 'dF', 'F', 'fd', 'Br', 'Dfr', 'Dr', 'r', 'rfd', 'RFd', 'Fdr', 'dfR', 'rb', 'fDr', 'rFD', 'fRd', 'Rfd', 'RDF', 'rFd', 'Rdf', 'rF', 'FDr', 'drF', 'dR', 'D', 'br', 'fr', 'drf', 'DrF', 'rd', 'DRF', 'DR', 'RFD', 'Rf', 'fR', 'RfD', 'Df', 'rDf', 'U', 'f', 'df', 'DRf', 'fdr', 'B', 'FRD', 'RF', 'Fd', 'Rd', 'fRD', 'FRd', 'b', 'dRf', 'FDR', 'RD', 'fDR', 'rfD'} I guess it's debatable if you want to count prefixes that contain 'b' as string prefixes or not, but the tokenizer thinks they are. If you leave them out, you come up with the 14 and 80 that Steven mentions. I agree with Terry that adding 'F' was a mistake. But since the upper case versions of 'r', and 'b' already existed, it was included. Interestingly, in 2.7 'ur' is a valid prefix, but not in 3.6. I don't recall if that was deliberate or not. And 'ru' isn't valid in either version. Eric

On 1 April 2018 at 19:24, Chris Angelico wrote:

Since the entire point of the Py3 u"..." prefix is compatibility with Py2, the semantics have to be retained. There's no point supporting ur"..." in Py3 if it's not going to produce the same result as in Py2.

Right, "ur" strings were originally taken out in Python 3.0, and then we made the decision *not* to add them back when PEP 414 restored other uses of the "u" prefix: https://www.python.org/dev/peps/pep-0414/#exclusion-of-raw-unicode-literals Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On Sun, Apr 01, 2018 at 08:08:41AM -0400, Richard Damon wrote:

One comment about the 'combitorial explosion' is that it sort of assumes that each individual combination case needs to be handled with distinct code.

No -- as I said in an earlier post, Terry and I (and Eric) are talking about the explosion in number of prefixes, not the complexity of the code. You are right that many of the prefixes can be handled by the same code: rfd rfD rFd rFD rdf rdF rDf rDF Rfd RfD RFd RFD Rdf RdF RDf RDF frd frD fRd fRD fdr fdR fDr fDR Frd FrD FRd FRD Fdr FdR FDr FDR drf drF dRf dRF dfr dfR dFr dFR Drf DrF DRf DRF Dfr DfR DFr DFR # why did we support all these combinations? who uses them? presumably will all handled by the same "raw dedent f-string" code. But the parser still has to handle all those cases, and so does the person reading the code. And that *mental complexity* is (in my opinion) the biggest issue with adding a new d-prefix, and why I would rather make it a method. Another big advantage of a method is that we can apply it to non-literals too. The number of code paths increases too, but not anywhere as fast: # existing - regular ("cooked") triple-quoted string; - raw string; - f-string - raw f-string # proposed additions - dedent string - raw dedent string - dedent f-string - raw dedent f-string so roughly doubling the number of cases. I doubt that will double the code complexity, but it will complicate it somewhat. Apart from parsing, the actual complexity to the code will probably be similar whether it is a method or a prefix. After all, whichever we do, we still need built-in dedent code. -- Steve

On 4/1/2018 8:55 AM, Chris Angelico wrote:

On Sun, Apr 1, 2018 at 10:36 PM, Steven D'Aprano wrote:

...

And that *mental complexity* is (in my opinion) the biggest issue with adding a new d-prefix, and why I would rather make it a method.

Another big advantage of a method is that we can apply it to non-literals too.

I'd like to expand on this a bit more.

Current string prefix letters are:

* u/b: completely change the object you're creating * f: change it from a literal to a kind of expression * r: change the interpretation of backslashes * triple quotes: change the interpretation of newlines

All of these are significant *to the parser*. You absolutely cannot do any of these with methods (well, maybe you could have u/b done by having a literal for one of them, and the other is an encode or decode operation, but that's a pretty poor hack).

The one place where a dedented string would come in handy, and where it would need to be recognized by the parser (and could not be the result of a function or method) is a docstring. Well, I guess you could have the parser "know" about certain string methods, but that seems horrible. Eric

But dedenting a string doesn't change the way the source code is interpreted. So it's free to be a method - which is far easier to add to the language. All you need is ".dedent()" to be syntactically parsed as a method call (which it already is), and every tool that processes Python code will correctly interpret this.

So here's what, IMO, Marius can push for:

1) A method on Unicode strings which does the same as textwrap.dedent() 2) A peephole optimization wherein certain methods on literals get executed at compile time.

The latter optimization would also apply to cases such as " spam ".strip() - as long as all it does is return another constant value, it can be done at compile time. Semantically, though, the part that matters is simply the new method. (Sadly, this can't be applied to Decimal("1.234"), as that's not a method and could be shadowed/mocked.)

While I wouldn't use that method much myself, I think it's a Good Thing for features like that to be methods rather than functions stashed away in a module. (How do you know to look in "textwrap" for a line-by-line version of x.strip() ??) So I would be +1 on both the enhancements I mentioned above, and a solid -1 on this becoming a new form of literal.

ChrisA _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

Hey again, Thx all for the active discussion. Since I‘m the OP and though want to make clear that I didn‘t had a `d` string literal in mind. So the Idea was to support this just as default, with any more effords to support it I don‘t see a real advantage or that I‘d think it is ‚solved‘. So I‘m aware that probably there won‘t be a majority to have this considering a breaking change - still I want to emphasize that I wouldn‘t want yet another string literal. I think this would be really bad. Actually I‘d rather like to see Python develop backwards and remove string literals and not getting even more ... so maybe just `r` and `b`? Anyways, I think I‘ve made my Point clear. Terry Reedy schrieb am So. 1. Apr. 2018 um 21:12:

On 4/1/2018 8:36 AM, Steven D'Aprano wrote:

...

On Sun, Apr 01, 2018 at 08:08:41AM -0400, Richard Damon wrote:

...

One comment about the 'combinatorial explosion' is that it sort of assumes that each individual combination case needs to be handled with distinct code.

...

No -- as I said in an earlier post, Terry and I (and Eric) are talking about the explosion in number of prefixes, not the complexity of the code.

You are right that many of the prefixes can be handled by the same code:

rfd rfD rFd rFD rdf rdF rDf rDF Rfd RfD RFd RFD Rdf RdF RDf RDF frd frD fRd fRD fdr fdR fDr fDR Frd FrD FRd FRD Fdr FdR FDr FDR drf drF dRf dRF dfr dfR dFr dFR Drf DrF DRf DRF Dfr DfR DFr DFR # why did we support all these combinations? who uses them?

presumably will all handled by the same "raw dedent f-string" code. But the parser still has to handle all those cases, and so does the person reading the code.

IDLE's colorizer does its parsing with a giant regex. The new prefix combinations would nearly double the number of alternatives in the regex. I am sure that this would mean more nodes in the compiled finite-state machine. Even though the non-re code of the colorizer would not change, I am pretty sure that this would mean that coloring takes longer. Since the colorizer is called with each keystroke*, and since other events can be handled between keystrokes#, colorizing time *could* become an issue, especially on older or slower machines than mine. Noticeable delays between keystroke and character appearance on screen are a real drag.

* Type 'i', 'i' appears 'normal'; type 'n', 'in' is colored 'keyword'; type 't', 'int' is colored 'builtin'; type 'o', 'into' becomes 'normal' again.

# One can edit while a program is running in a separate process and outputting to the shell window.

-- Terry Jan Reedy

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

On 2018-04-01 20:10, Terry Reedy wrote:

On 4/1/2018 8:36 AM, Steven D'Aprano wrote:

...

On Sun, Apr 01, 2018 at 08:08:41AM -0400, Richard Damon wrote:

...

One comment about the 'combinatorial explosion' is that it sort of assumes that each individual combination case needs to be handled with distinct code.

...

No -- as I said in an earlier post, Terry and I (and Eric) are talking about the explosion in number of prefixes, not the complexity of the code.

You are right that many of the prefixes can be handled by the same code:

rfd rfD rFd rFD rdf rdF rDf rDF Rfd RfD RFd RFD Rdf RdF RDf RDF frd frD fRd fRD fdr fdR fDr fDR Frd FrD FRd FRD Fdr FdR FDr FDR drf drF dRf dRF dfr dfR dFr dFR Drf DrF DRf DRF Dfr DfR DFr DFR # why did we support all these combinations? who uses them?

presumably will all handled by the same "raw dedent f-string" code. But the parser still has to handle all those cases, and so does the person reading the code.

IDLE's colorizer does its parsing with a giant regex. The new prefix combinations would nearly double the number of alternatives in the regex. I am sure that this would mean more nodes in the compiled finite-state machine. Even though the non-re code of the colorizer would not change, I am pretty sure that this would mean that coloring takes longer. Since the colorizer is called with each keystroke*, and since other events can be handled between keystrokes#, colorizing time *could* become an issue, especially on older or slower machines than mine. Noticeable delays between keystroke and character appearance on screen are a real drag.

In Python 3.7 that part is now: stringprefix = r"(?i:\br|u|f|fr|rf|b|br|rb)?" (which looks slightly wrong to me!).

On 2018-04-01 05:36, Steven D'Aprano wrote:

On Sun, Apr 01, 2018 at 08:08:41AM -0400, Richard Damon wrote:

...

One comment about the 'combitorial explosion' is that it sort of assumes that each individual combination case needs to be handled with distinct code.

No -- as I said in an earlier post, Terry and I (and Eric) are talking about the explosion in number of prefixes, not the complexity of the code.

You are right that many of the prefixes can be handled by the same code:

rfd rfD rFd rFD rdf rdF rDf rDF Rfd RfD RFd RFD Rdf RdF RDf RDF frd frD fRd fRD fdr fdR fDr fDR Frd FrD FRd FRD Fdr FdR FDr FDR drf drF dRf dRF dfr dfR dFr dFR Drf DrF DRf DRF Dfr DfR DFr DFR # why did we support all these combinations? who uses them?

presumably will all handled by the same "raw dedent f-string" code. But the parser still has to handle all those cases, and so does the person reading the code.

And that *mental complexity* is (in my opinion) the biggest issue with adding a new d-prefix, and why I would rather make it a method.

That doesn't seem a very reasonable argument to me. That is like saying that a person reading code has to mentally slog through the cognitive burden of understanding "all the combinations" of "a + b + c", "a + b - c", "a * b + c", "a - b * c", etc. We don't. We know what the operators mean and we build up our understanding of expressions by combining them. Similarly, these string prefixes can mostly be thought of as indepedent flags. You don't parse each combination separately; you learn what each flag means and then build up your understanding of a prefix by combining your understanding of the flags. (This is also glossing over the fact that many of the combinations you list differ only in case, which to my mind adds no extra cognitive load whatsoever.) -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown

On 2018-04-01 05:36, Steven D'Aprano wrote:

You are right that many of the prefixes can be handled by the same code:

rfd rfD rFd rFD rdf rdF rDf rDF Rfd RfD RFd RFD Rdf RdF RDf RDF frd frD fRd fRD fdr fdR fDr fDR Frd FrD FRd FRD Fdr FdR FDr FDR drf drF dRf dRF dfr dfR dFr dFR Drf DrF DRf DRF Dfr DfR DFr DFR # why did we support all these combinations? who uses them?

In almost twenty years of using Python, I've not seen capital string prefixes in real code, ever. Sounds like a great candidate for deprecation? -Mike

On 2018-04-02 10:53, Michel Desmoulin wrote:

Le 02/04/2018 à 07:09, Mike Miller a écrit :

...

On 2018-04-01 05:36, Steven D'Aprano wrote:

...

You are right that many of the prefixes can be handled by the same code:

     rfd rfD rFd rFD rdf rdF rDf rDF      Rfd RfD RFd RFD Rdf RdF RDf RDF      frd frD fRd fRD fdr fdR fDr fDR      Frd FrD FRd FRD Fdr FdR FDr FDR      drf drF dRf dRF dfr dfR dFr dFR      Drf DrF DRf DRF Dfr DfR DFr DFR      # why did we support all these combinations? who uses them?

In almost twenty years of using Python, I've not seen capital string prefixes in real code, ever.  Sounds like a great candidate for deprecation?

+1

It's not like migrating would be hard: a replace is enough to fix the rare projects doing that. And even if they missed the warning, it's a syntax error anyway, so you will get the error as soon as you try to run the program, not at a later point at runtime.

What about doing a poll, then suggests a warning on 3.8, removed in 4.0 ?

Also, Python is case-sensitive elsewhere, so why not here too? OTOH, it's not like it's causing a problem.

On 01/04/2018 02:48, Steven D'Aprano wrote:

On Sun, Apr 01, 2018 at 02:20:16AM +0100, Rob Cliffe via Python-ideas wrote:

...

...

New unordered 'd' and 'D' prefixes, for 'dedent', applied to multiline strings only, would multiply the number of alternatives by about 5 and would require another rewrite of all code (Python or not) that parses Python code (such as in syntax colorizers).

I think you're exaggerating the difficulty somewhat.  Multiplying the number of alternatives by 5 is not the same thing as increasing the complexity of code to parse it by 5.

Terry didn't say that it would increase the complexity of the code by a factor of five. He said it would multiply the number of alternatives by "about 5". There would be a significant increase in the complexity of the code too, but I wouldn't want to guess how much.

Starting with r and f prefixes, in both upper and lower case, we have:

4 single letter prefixes (plus 2 more, u and U, that don't combine with others) 8 double letter prefixes

making 14 in total. Adding one more prefix, d|D, increases it to:

6 single letter prefixes (plus 2 more, u and U) 24 double letter prefixes 48 triple letter prefixes

making 80 prefixes in total. Terry actually underestimated the explosion in prefixes: it is closer to six times more than five (but who is counting? apart from me *wink*)

[Aside: if we add a fourth, the total becomes 634 prefixes.]

Can I suggest, rather than another string prefix, that will require the user to add the d flag to every string that they use, we consider a file scope dedent_multiline or auto_dedent import, possibly from __future__ or textwrap, that automatically applies the dedent function to all multiline strings in the file. This would reflect that, typically, a specific developer tends to want either all or no multi-line text strings dedented. It should have minimumal impact on the language, operate at compile time so be low overhead and avoid cluttering strings up. -- Steve (Gadget) Barnes Any opinions in this message are my personal opinions and do not reflect those of my employer. --- This email has been checked for viruses by AVG. http://www.avg.com

On 2 April 2018 at 23:06, Steven D'Aprano wrote:

On Mon, Apr 02, 2018 at 12:08:47PM +0000, Steve Barnes wrote:

...

This would reflect that, typically, a specific developer tends to want either all or no multi-line text strings dedented.

I don't know how you come to that conclusion.

I certainly would not want "All or Nothing" when it comes to dedenting triple-quoted strings.

If we did flip the default with a "from __future__ import auto_dedent" though, there would be an opportunity to consider the available approaches for *adding* indentation after the fact, such as: indented = textwrap.indent(text, " " * 8) or: indent = " " * 8 indented = "\n".join((indent + line if line else line) for line in text.splitlines()) Adding indentation is generally easier than removing it, since you can operate on each line in isolation, rather than having to work out the common prefix. To allow exact recreation of the current indented multi-line string behaviour, we could offer an `__indent__` constant, which the compiler replaced with the leading indent of the current code block (Note: not necessarily the indent level of the current line). So where today we have: * leading indent by default * "textwrap.dedent(text)" to strip the common leading whitespace In an auto-dedent world, we'd have: * the current block indent level stripped from each line after the first in multi-line strings by default * add it back by doing "textwrap.indent(text, __indent__)" in the same code block I mostly find the current behaviour irritating, and work around it by way of module level constants, but even so, I'm still not sure it qualifies as being annoying enough to be worth the hassle of changing it. One relevant point though is that passing an already dedented string through textwrap.dedent() will be a no-op, so the compatibility cases to worry about will be those where *all* of the leading whitespace in a multiline string is significant, including the common prefix arising from the code block indentation. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

Was: "Dart (Swift) like multi line strings indentation" This discussion petered-out but I liked the idea, as it alleviates something occasionally annoying. Am supportive of the d'' prefix, perhaps the capital prefixes can be deprecated to avoid issues? If not, a sometimes-optimized (or C-accelerated) str.dedent() is acceptable too. Anyone still interested in this? -Mike On 3/31/18 5:43 PM, Steven D'Aprano wrote:

The ideal solution would:

- require only a single pair of starting/ending string delimiters;

- allow string literals to be indented to the current block, for the visual look and to make it more convenient with editors which automatically indent;

- evaluate without the indents;

- with no runtime cost.

One solution is to add yet another string prefix, let's say d for dedent, but as Terry and others point out, that leads to a combinational explosion with f-strings and r-strings already existing.

Another possibility is to make dedent a string method:

def spam(): text = """\ some text another line and a third """.dedent() print(text)

and avoid the import of textwrap. However, that also imposes a runtime cost, which could be expensive if you are careless:

for x in seq: for y in another_seq: process("""/ some large indented string """.dedent() )

(Note: the same applies to using textwrap.dedent.)

But we could avoid that runtime cost if the keyhole optimizer performed the dedent at compile time:

triple-quoted string literal .dedent()

could be optimized at compile-time, like other constant-folding.

Out of all the options, including the status quo, the one I dislike the least is the last one:

- make dedent a string method;

- recommend (but don't require) that implementations perform the dedent of string literals at compile time;

(failure to do so is a quality of implementation issue, not a bug)

- textwrap.dedent then becomes a thin wrapper around the string method.

On 4/1/18 4:41 AM, Michel Desmoulin wrote:>

A "d" prefix to do textwrap.dedent is something I wished for a long time.

It's like the "f" one: we already can do it, be hell is it convenient to have a shortcut.

This is especially if, like me, you take a lot of care in the error messages you give to the user. I write a LOT of them, very long, very descriptive, and I have to either import textwrap or play the concatenation game.

Having a str.dedent() method would be nice, but the d prefix has the huge advantage to be able to dedent on parsing, and hence be more performant.

I particularly like the str.dedent() idea. Adding yet another string prefix adds more complexity to the language, which I'm generally not in favor of. On 2/7/19, Mike Miller wrote:

Was: "Dart (Swift) like multi line strings indentation"

This discussion petered-out but I liked the idea, as it alleviates something

occasionally annoying.

Am supportive of the d'' prefix, perhaps the capital prefixes can be deprecated to avoid issues? If not, a sometimes-optimized (or C-accelerated) str.dedent() is acceptable too.

Anyone still interested in this?

-Mike

On 3/31/18 5:43 PM, Steven D'Aprano wrote:

...

The ideal solution would:

- require only a single pair of starting/ending string delimiters;

- allow string literals to be indented to the current block, for the visual look and to make it more convenient with editors which automatically indent;

- evaluate without the indents;

- with no runtime cost.

One solution is to add yet another string prefix, let's say d for dedent, but as Terry and others point out, that leads to a combinational explosion with f-strings and r-strings already existing.

Another possibility is to make dedent a string method:

def spam(): text = """\ some text another line and a third """.dedent() print(text)

and avoid the import of textwrap. However, that also imposes a runtime cost, which could be expensive if you are careless:

for x in seq: for y in another_seq: process("""/ some large indented string """.dedent() )

(Note: the same applies to using textwrap.dedent.)

But we could avoid that runtime cost if the keyhole optimizer performed the dedent at compile time:

triple-quoted string literal .dedent()

could be optimized at compile-time, like other constant-folding.

Out of all the options, including the status quo, the one I dislike the least is the last one:

- make dedent a string method;

- recommend (but don't require) that implementations perform the dedent of string literals at compile time;

(failure to do so is a quality of implementation issue, not a bug)

- textwrap.dedent then becomes a thin wrapper around the string method.

On 4/1/18 4:41 AM, Michel Desmoulin wrote:>

...

A "d" prefix to do textwrap.dedent is something I wished for a long time.

It's like the "f" one: we already can do it, be hell is it convenient to have a shortcut.

This is especially if, like me, you take a lot of care in the error messages you give to the user. I write a LOT of them, very long, very descriptive, and I have to either import textwrap or play the concatenation game.

Having a str.dedent() method would be nice, but the d prefix has the huge advantage to be able to dedent on parsing, and hence be more performant.

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

-- Paul Ferrell pflarr@gmail.com

On Thu, 7 Feb 2019 at 18:21, Mike Miller wrote:

Anyone still interested in this?

It feels like a nice idea to me, when reading the proposals. However, in all of the code I've ever written in Python (and that's quite a lot...) I've never actually had a case where I this feature would have made a significant difference to the code I wrote. Maybe that says more about my coding style than about the usefulness of the feature, but personally I don't think it's worth it. Paul PS Although I could probably have said something similar about f-strings, and now I use them all the time. Language design is hard ;-)

Thanks all, I'm willing to start work on a PEP, perhaps next week. Unless Marius would prefer to do it. One fly in the ointment is that I don't feel strongly about the choice of solution 1, 2, or last-minute entry. -Mike

not that anyone asked, but I"d only support:

2a) Adding a str.dedent() method

and maybe:

2b) Creating a constant-folding peephole optimization for methods on immutable literals

and frankly, it's a much lighter lift to get approval than: 1) Creating a new type of string literal which compiles to a dedented form of multiline string Also -- more useful -- dedent() is helpful for non-literals as well. Other than docstrings, the case for literals is pretty small, and docstrings are already auto-cleaned up.

in all of the code I've ever written in Python (and that's quite a

...

lot...) I've never actually had a case where I this feature would have made a significant difference to the code I wrote.

exactly -- I do have one case -- but that's for an instructional exercise where we are keeping things simple -- in operational code that string would have been in a file, or database, or .... -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython