Idea for new multi-line triple quote literal
The tripple quote string literal is a great feature, but there is one problem. When you use them, it forces you to break out of you're current indentation which maks code look ugly. I propose a new way to define a triple back quote that woks the same way regular triple quotes work, but instead does some simple parsing of the data within the quotes to preserve the flow of the code. Due to the brittle and sometimes ambigious nature of anything 'automatic', this feature is obviously not meant for data where exact white space is needed. It would be great for docstrings, exception messages and other type text. Here is a short example of it's usage: https://gist.github.com/priestc/5897602
Hi nbv4, and welcome. On 01/07/13 10:32, nbv4 wrote:
The tripple quote string literal is a great feature, but there is one problem. When you use them, it forces you to break out of you're current indentation which maks code look ugly. I propose a new way to define a triple back quote that woks the same way regular triple quotes work, but instead does some simple parsing of the data within the quotes to preserve the flow of the code. Due to the brittle and sometimes ambigious nature of anything 'automatic', this feature is obviously not meant for data where exact white space is needed. It would be great for docstrings, exception messages and other type text.
Here is a short example of it's usage: https://gist.github.com/priestc/5897602
For something as trivial as the example you give, there is no need to send people off to a website, which they may not have access too. Here's the simplified version: # Proposed syntax def func(): s = """line 1 line 2 line 3""" t = ---line 1 line 2 line 3--- return s, t The difference being, lines 2 and 3 of s will begin with four spaces, while t reduces the whitespace between lines to a single space: s == 'line 1\n line 2\n line 3' t == 'line 1 line 2 line 3' I don't think this is particularly useful. I would be more interested in it if it kept the newlines but got rid of the leading spaces: t == 'line 1\nline 2\nline 3' but in either case, I think the choice of --- as delimiter is ugly and arbitrary, and very likely is ambiguous (currently, x = ---1 is legal code). Similar suggestions to this have been made many times before, you should search the archives: http://mail.python.org/mailman/listinfo/python-ideas Regards, -- Steven
On 1 July 2013 11:09, Steven D'Aprano <steve@pearwood.info> wrote:
but in either case, I think the choice of --- as delimiter is ugly and arbitrary, and very likely is ambiguous (currently, x = ---1 is legal code). Similar suggestions to this have been made many times before, you should search the archives:
I'm still partial to the idea of offering textwrap.indent() and textwrap.dedent() as string methods. 1. You could add a ".dedent()" at the end of a triple quoted string for this kind of problem. For a lot of code, the runtime cost isn't an issue. 2. A JIT would definitely be able to avoid recalculating the result every time 3. Even CPython may eventually gain constant folding for that kind of method applied directly to a string literal 4. I dedent and indent long strings more often than I capitalize, center, tab expand, or perform various other operations which already grace the str type as methods. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Sun, Jun 30, 2013 at 6:47 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 1 July 2013 11:09, Steven D'Aprano <steve@pearwood.info> wrote:
but in either case, I think the choice of --- as delimiter is ugly and arbitrary, and very likely is ambiguous (currently, x = ---1 is legal code). Similar suggestions to this have been made many times before, you should search the archives:
I'm still partial to the idea of offering textwrap.indent() and textwrap.dedent() as string methods.
1. You could add a ".dedent()" at the end of a triple quoted string for this kind of problem. For a lot of code, the runtime cost isn't an issue. 2. A JIT would definitely be able to avoid recalculating the result every time 3. Even CPython may eventually gain constant folding for that kind of method applied directly to a string literal 4. I dedent and indent long strings more often than I capitalize, center, tab expand, or perform various other operations which already grace the str type as methods.
That's a compelling argument. Let's do it. (Assuming the definition of exactly how to indent or dedent is not up for discussion -- if there are good reasons to disagree with textwrap now's the time to bring it up.) -- --Guido van Rossum (python.org/~guido)
On 6/30/2013 9:57 PM, Guido van Rossum wrote:
That's a compelling argument. Let's do it. http://bugs.python.org/issue18335
-- Terry Jan Reedy
Maybe "dedent" should be replaced with "outdent", while keeping the old names for compatibility. On Mon, Jul 1, 2013 at 1:34 AM, Terry Reedy <tjreedy@udel.edu> wrote:
On 6/30/2013 9:57 PM, Guido van Rossum wrote:
That's a compelling argument. Let's do it.
http://bugs.python.org/issue18335
-- Terry Jan Reedy
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
On 06/30/2013 08:57 PM, Guido van Rossum wrote:
On Sun, Jun 30, 2013 at 6:47 PM, Nick Coghlan<ncoghlan@gmail.com> wrote:
On 1 July 2013 11:09, Steven D'Aprano<steve@pearwood.info> wrote:
but in either case, I think the choice of --- as delimiter is ugly and arbitrary, and very likely is ambiguous (currently, x = ---1 is legal code). Similar suggestions to this have been made many times before, you should search the archives:
I'm still partial to the idea of offering textwrap.indent() and textwrap.dedent() as string methods.
1. You could add a ".dedent()" at the end of a triple quoted string for this kind of problem. For a lot of code, the runtime cost isn't an issue. 2. A JIT would definitely be able to avoid recalculating the result every time 3. Even CPython may eventually gain constant folding for that kind of method applied directly to a string literal 4. I dedent and indent long strings more often than I capitalize, center, tab expand, or perform various other operations which already grace the str type as methods. That's a compelling argument. Let's do it. (Assuming the definition of exactly how to indent or dedent is not up for discussion -- if there are good reasons to disagree with textwrap now's the time to bring it up.)
It would be an improvement to have them as methods, but I'd actually like to have Str.indent(n) method that takes a value for the leading white space. The value to this method would always be a positive number, and any common leading white space would be replaced by the new indent amount. S.indent(0) would be the same as S.dedent(). s = """\ A multi-line string with 4 leading spaces. """.indent(4) s = """\ A multi-line string with 4 leading spaces. """.indent(4) if cond: s = """\ Another multi-line string with 4 leading spaces. """.indent(4) The reason I prefer this is ... It's more relevant to what I'm going to use the string for and is not just compensating for the block indention level, which has nothing to do with how I'm going to use the string. It explicitly specifies the amount of leading white space I want in the resulting string object. If I want a different indent level, I can just change the value. Or call the indent method again with the new value. I don't need to know what the current leading white space is on the string, just what I want for my output. Strangely, the online docs for textwrap include an indent function that works a bit different, but it is no longer present in textwrap. Looks like an over site to me. Cheers, Ron
Textwrap.indent already exists, but was added in Python 3.3. Maybe you're using an earlier interpreter but looking at the Python 3.3 docs? On Mon, Jul 1, 2013 at 1:56 AM, Ron Adam <ron3200@gmail.com> wrote:
On 06/30/2013 08:57 PM, Guido van Rossum wrote:
On Sun, Jun 30, 2013 at 6:47 PM, Nick Coghlan<ncoghlan@gmail.com> wrote:
On 1 July 2013 11:09, Steven D'Aprano<steve@pearwood.info> wrote:
but in either case, I think the choice of --- as delimiter is ugly and arbitrary, and very likely is ambiguous (currently, x = ---1 is legal code). Similar suggestions to this have been made many times before, you should search the archives:
I'm still partial to the idea of offering textwrap.indent() and textwrap.dedent() as string methods.
1. You could add a ".dedent()" at the end of a triple quoted string for this kind of problem. For a lot of code, the runtime cost isn't an issue. 2. A JIT would definitely be able to avoid recalculating the result every time 3. Even CPython may eventually gain constant folding for that kind of method applied directly to a string literal 4. I dedent and indent long strings more often than I capitalize, center, tab expand, or perform various other operations which already grace the str type as methods.
That's a compelling argument. Let's do it. (Assuming the definition of exactly how to indent or dedent is not up for discussion -- if there are good reasons to disagree with textwrap now's the time to bring it up.)
It would be an improvement to have them as methods, but I'd actually like to have Str.indent(n) method that takes a value for the leading white space.
The value to this method would always be a positive number, and any common leading white space would be replaced by the new indent amount.
S.indent(0) would be the same as S.dedent().
s = """\ A multi-line string with 4 leading spaces. """.indent(4)
s = """\ A multi-line string with 4 leading spaces. """.indent(4)
if cond: s = """\ Another multi-line string with 4 leading spaces. """.indent(4)
The reason I prefer this is ...
It's more relevant to what I'm going to use the string for and is not just compensating for the block indention level, which has nothing to do with how I'm going to use the string.
It explicitly specifies the amount of leading white space I want in the resulting string object. If I want a different indent level, I can just change the value. Or call the indent method again with the new value.
I don't need to know what the current leading white space is on the string, just what I want for my output.
Strangely, the online docs for textwrap include an indent function that works a bit different, but it is no longer present in textwrap. Looks like an over site to me.
Cheers, Ron
______________________________**_________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/**mailman/listinfo/python-ideas<http://mail.python.org/mailman/listinfo/python-ideas>
The only problem I see with explicitly passing in the number of characters to the dedent function is that you couple your code with th source of that code. What happens when you copy+paste that function to a class where the indention level does not match. You then will have to change that number, or else your code will break. Also, if you run your code through pylent or something and it changes your indenting from tabs to spaces. On Sunday, June 30, 2013 10:56:26 PM UTC-7, Ron Adam wrote:
On 06/30/2013 08:57 PM, Guido van Rossum wrote:
On Sun, Jun 30, 2013 at 6:47 PM, Nick Coghlan<ncog...@gmail.com<javascript:>> wrote:
On 1 July 2013 11:09, Steven D'Aprano<st...@pearwood.info<javascript:>> wrote:
but in either case, I think the choice of --- as delimiter is ugly and arbitrary, and very likely is ambiguous (currently, x = ---1 is legal code). Similar suggestions to this have been made many times before, you should search the archives:
I'm still partial to the idea of offering textwrap.indent() and textwrap.dedent() as string methods.
1. You could add a ".dedent()" at the end of a triple quoted string for this kind of problem. For a lot of code, the runtime cost isn't an issue. 2. A JIT would definitely be able to avoid recalculating the result every time 3. Even CPython may eventually gain constant folding for that kind of method applied directly to a string literal 4. I dedent and indent long strings more often than I capitalize, center, tab expand, or perform various other operations which already grace the str type as methods. That's a compelling argument. Let's do it. (Assuming the definition of exactly how to indent or dedent is not up for discussion -- if there are good reasons to disagree with textwrap now's the time to bring it up.)
It would be an improvement to have them as methods, but I'd actually like to have Str.indent(n) method that takes a value for the leading white space.
The value to this method would always be a positive number, and any common leading white space would be replaced by the new indent amount.
S.indent(0) would be the same as S.dedent().
s = """\ A multi-line string with 4 leading spaces. """.indent(4)
s = """\ A multi-line string with 4 leading spaces. """.indent(4)
if cond: s = """\ Another multi-line string with 4 leading spaces. """.indent(4)
The reason I prefer this is ...
It's more relevant to what I'm going to use the string for and is not just compensating for the block indention level, which has nothing to do with how I'm going to use the string.
It explicitly specifies the amount of leading white space I want in the resulting string object. If I want a different indent level, I can just change the value. Or call the indent method again with the new value.
I don't need to know what the current leading white space is on the string, just what I want for my output.
Strangely, the online docs for textwrap include an indent function that works a bit different, but it is no longer present in textwrap. Looks like an over site to me.
Cheers, Ron
_______________________________________________ Python-ideas mailing list Python...@python.org <javascript:> http://mail.python.org/mailman/listinfo/python-ideas
On 07/01/2013 12:08 PM, nbv4 wrote:
The only problem I see with explicitly passing in the number of characters to the dedent function is that you couple your code with th source of that code. What happens when you copy+paste that function to a class where the indention level does not match. You then will have to change that number, or else your code will break. Also, if you run your code through pylent or something and it changes your indenting from tabs to spaces.
The number isn't how much to dedent. But how much white space each non-blank line should have at the beginning. s.margin(0) # remove common leading space like dedent(). s.margin(4) # specifies it to have 4 spaces. No matter how much (or little) it's indented in your code, it will still be exactly and explicitly what you specify in the string... s1 = """ This string is indented 4 spaces in the source code, but will have a margin of 24 spaces when printed.""".margin(24) s2 = """ This string is indented 12 spaces in the source code, but will have a margin of 4 spaces when it's printed.""".margin(4) Use .margin(0), and it removes all the common leading white space just like dedent. (Makes dedent redundant) Lets say you want to use a string in different places. For example on the screen you might want it to be 4 spaces, and on a printed out log you would like it to be 8 spaces. And in your source code it is indented 12 spaces. s3 = \ """ This is an output string I'm going to use in several places with different margins. """ print(s3.margin(4)) # to the screen with a margin of 4. print(s3.margin(8), file=logfile) # with a margin of 8. Notice that the indention level of the initial string doesn't matter. Cheers, Ron What you are thinking of is a relative indent/dedent method. That would be completely different. You would have to specify how much to remove or add, and each time you use it on the string it would remove or add that amount again. So no, that isn't what I'm suggesting. Cheers, Ron
If you want specific indentation, then use the regular triple quote and write it exactly how you want it. On the other hand, the 99% use case (in my experience at least) you don't care about eh indentation. All you care about is the words. This is the usecase for triple backtick. The most common example is exceptions. When I raise exceptions, I like to include long, verbose error messages. Right now I have three options: raise TypeError(Live with a really long string going past the 80 char limit, thus breaking PEP8 and being annoying") or raise TypeError(""" Use a triple string But then live with extra newlines and indentation. The suggestion to have a dedent method makes things a little better But imo still not ideal. """.strip().dedent().replace("/n', ' ')) raise TypeError("Another Option is to " "do it like this, but if you do it this way " "you run the risk of forgetting a trailing" "space at the end of each line and other errors." "Not to mention it's annoying when you want to " "add words because you have to rewrap and its " "generally really annoying to have to deal with") raise TypeError(``` The best solution is a new type of string literal that just deals with the text so I don't have to worry about a thing. This is only meant for text where I don't need explicit indenting and/or whitespace requirements. ```) On Monday, July 1, 2013 11:12:30 AM UTC-7, Ron Adam wrote:
The only problem I see with explicitly passing in the number of characters to the dedent function is that you couple your code with th source of
code. What happens when you copy+paste that function to a class where
On 07/01/2013 12:08 PM, nbv4 wrote: that the
indention level does not match. You then will have to change that number, or else your code will break. Also, if you run your code through pylent or something and it changes your indenting from tabs to spaces.
The number isn't how much to dedent. But how much white space each non-blank line should have at the beginning.
s.margin(0) # remove common leading space like dedent().
s.margin(4) # specifies it to have 4 spaces.
No matter how much (or little) it's indented in your code, it will still be exactly and explicitly what you specify in the string...
s1 = """ This string is indented 4 spaces in the source code, but will have a margin of 24 spaces when printed.""".margin(24)
s2 = """ This string is indented 12 spaces in the source code, but will have a margin of 4 spaces when it's printed.""".margin(4)
Use .margin(0), and it removes all the common leading white space just like dedent. (Makes dedent redundant)
Lets say you want to use a string in different places. For example on the screen you might want it to be 4 spaces, and on a printed out log you would like it to be 8 spaces. And in your source code it is indented 12 spaces.
s3 = \ """ This is an output string I'm going to use in several places with different margins. """
print(s3.margin(4)) # to the screen with a margin of 4. print(s3.margin(8), file=logfile) # with a margin of 8.
Notice that the indention level of the initial string doesn't matter.
Cheers, Ron
What you are thinking of is a relative indent/dedent method. That would be completely different. You would have to specify how much to remove or add, and each time you use it on the string it would remove or add that amount again. So no, that isn't what I'm suggesting.
Cheers, Ron
_______________________________________________ Python-ideas mailing list Python...@python.org <javascript:> http://mail.python.org/mailman/listinfo/python-ideas
On 1 July 2013 11:57, Guido van Rossum <guido@python.org> wrote:
On Sun, Jun 30, 2013 at 6:47 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 1 July 2013 11:09, Steven D'Aprano <steve@pearwood.info> wrote:
but in either case, I think the choice of --- as delimiter is ugly and arbitrary, and very likely is ambiguous (currently, x = ---1 is legal code). Similar suggestions to this have been made many times before, you should search the archives:
I'm still partial to the idea of offering textwrap.indent() and textwrap.dedent() as string methods.
1. You could add a ".dedent()" at the end of a triple quoted string for this kind of problem. For a lot of code, the runtime cost isn't an issue. 2. A JIT would definitely be able to avoid recalculating the result every time 3. Even CPython may eventually gain constant folding for that kind of method applied directly to a string literal 4. I dedent and indent long strings more often than I capitalize, center, tab expand, or perform various other operations which already grace the str type as methods.
That's a compelling argument. Let's do it. (Assuming the definition of exactly how to indent or dedent is not up for discussion -- if there are good reasons to disagree with textwrap now's the time to bring it up.)
The only slight quirk that occurred to me is that if dedent is a method, people will probably want to use them with docstrings, and the compiler currently doesn't allow that. There are then two options for changing the compiler (if we decide we want to allow for "neat" docstrings): 1. Implicitly call dedent on docstrings at compilation time (feasible with dedent as a method). 2. Allow method calls on docstrings without breaking docstring detection It's technically a separate question from the decision on whether or not to add the methods, but I figured it was worth bringing up. Touching the methods of a builtin *and* possibly the compiler behaviour as well is likely enough to nudge the idea into PEP territory. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
There is another problem with running dedent on docstrings, I believe: a PEP 257 <http://www.python.org/dev/peps/pep-0257/> compliant docstring with a summary line won't dedent at all, since the first line lacks indentation. If you wanted to automatically clean docstrings, I think you would want to use the trim(docstring) function from PEP 257, rather than dedent. But I'm guessing there was a reason this has not been done before. On Mon, Jul 1, 2013 at 5:05 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 1 July 2013 11:57, Guido van Rossum <guido@python.org> wrote:
On Sun, Jun 30, 2013 at 6:47 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 1 July 2013 11:09, Steven D'Aprano <steve@pearwood.info> wrote:
but in either case, I think the choice of --- as delimiter is ugly and arbitrary, and very likely is ambiguous (currently, x = ---1 is legal code). Similar suggestions to this have been made many times before, you should search the archives:
I'm still partial to the idea of offering textwrap.indent() and textwrap.dedent() as string methods.
1. You could add a ".dedent()" at the end of a triple quoted string for this kind of problem. For a lot of code, the runtime cost isn't an issue. 2. A JIT would definitely be able to avoid recalculating the result every time 3. Even CPython may eventually gain constant folding for that kind of method applied directly to a string literal 4. I dedent and indent long strings more often than I capitalize, center, tab expand, or perform various other operations which already grace the str type as methods.
That's a compelling argument. Let's do it. (Assuming the definition of exactly how to indent or dedent is not up for discussion -- if there are good reasons to disagree with textwrap now's the time to bring it up.)
The only slight quirk that occurred to me is that if dedent is a method, people will probably want to use them with docstrings, and the compiler currently doesn't allow that.
There are then two options for changing the compiler (if we decide we want to allow for "neat" docstrings):
1. Implicitly call dedent on docstrings at compilation time (feasible with dedent as a method). 2. Allow method calls on docstrings without breaking docstring detection
It's technically a separate question from the decision on whether or not to add the methods, but I figured it was worth bringing up. Touching the methods of a builtin *and* possibly the compiler behaviour as well is likely enough to nudge the idea into PEP territory.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
On 1 Jul 2013 22:39, "Daniel Robinson" <gottagetmac@gmail.com> wrote:
There is another problem with running dedent on docstrings, I believe: a
PEP 257 compliant docstring with a summary line won't dedent at all, since the first line lacks indentation.
If you wanted to automatically clean docstrings, I think you would want
to use the trim(docstring) function from PEP 257, rather than dedent. But I'm guessing there was a reason this has not been done before. I did think of that, and considered the fact existing docstrings would generally be left alone to be a feature rather than a bug. Regardless, this is all idle speculation unless/until someone comes up with a draft patch to add at least dedent, and perhaps indent, as string methods. It shouldn't be too tricky, but it's still C code. Cheers, Nick.
On Mon, Jul 1, 2013 at 5:05 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 1 July 2013 11:57, Guido van Rossum <guido@python.org> wrote:
On Sun, Jun 30, 2013 at 6:47 PM, Nick Coghlan <ncoghlan@gmail.com>
On 1 July 2013 11:09, Steven D'Aprano <steve@pearwood.info> wrote:
but in either case, I think the choice of --- as delimiter is ugly and arbitrary, and very likely is ambiguous (currently, x = ---1 is legal code). Similar suggestions to this have been made many times before, you should search the archives:
I'm still partial to the idea of offering textwrap.indent() and textwrap.dedent() as string methods.
1. You could add a ".dedent()" at the end of a triple quoted string for this kind of problem. For a lot of code, the runtime cost isn't an issue. 2. A JIT would definitely be able to avoid recalculating the result every time 3. Even CPython may eventually gain constant folding for that kind of method applied directly to a string literal 4. I dedent and indent long strings more often than I capitalize, center, tab expand, or perform various other operations which already grace the str type as methods.
That's a compelling argument. Let's do it. (Assuming the definition of exactly how to indent or dedent is not up for discussion -- if there are good reasons to disagree with textwrap now's the time to bring it up.)
The only slight quirk that occurred to me is that if dedent is a method,
There are then two options for changing the compiler (if we decide we
want to allow for "neat" docstrings):
1. Implicitly call dedent on docstrings at compilation time (feasible
with dedent as a method).
2. Allow method calls on docstrings without breaking docstring detection
It's technically a separate question from the decision on whether or not to add the methods, but I figured it was worth bringing up. Touching the methods of a builtin *and* possibly the compiler behaviour as well is
wrote: people will probably want to use them with docstrings, and the compiler currently doesn't allow that. likely enough to nudge the idea into PEP territory.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
On 01/07/13 22:44, Nick Coghlan wrote:
On 1 Jul 2013 22:39, "Daniel Robinson" <gottagetmac@gmail.com> wrote:
There is another problem with running dedent on docstrings, I believe: a
PEP 257 compliant docstring with a summary line won't dedent at all, since the first line lacks indentation.
If you wanted to automatically clean docstrings, I think you would want
to use the trim(docstring) function from PEP 257, rather than dedent. But I'm guessing there was a reason this has not been done before.
I did think of that, and considered the fact existing docstrings would generally be left alone to be a feature rather than a bug.
+1 There's little reason to manually call dedent on a docstring, since pydoc will reformat it for display: py> def factory(): ... def inner(): ... """Doc string. ... ... Note the indentation. ... """ ... return inner ... py> help(factory()) Help on function inner in module __main__: inner() Doc string. Note the indentation. -- Steven
2013/7/1 Guido van Rossum guido@python.org That‘s a compelling argument. Let’s do it. (Assuming the definition of exactly how to indent or dedent is not up for discussion — if there are good reasons to disagree with textwrap now's the time to bring it up.) I don’t know if it’s a good reason, but I’m of the opinion that the required backslash at the beginning of to-be-dedented string is strange: We try to eliminate escaped newlines elsewhere (e.g. bracing import statements, conditions and tuple values is preferred to escaping newlines) I think dedent (or however it’s going to be called) should remove common whitespace and, if the first line is completely empty, that first line as well. Also for your consideration would be scala’s way: """|spam |eggs""".stripMargin() == "spam\neggs" """#spam #eggs""".stripMargin('#') == "spam\neggs" i.e. removal of all leading whitespace up to and including a margin character/prefix. It could be a kwarg to “dedent”…
On 01/07/2013 17:22, Philipp A. wrote:
2013/7/1 Guido van Rossum guido@python.org <mailto:guido@python.org>
That‘s a compelling argument. Let’s do it. (Assuming the definition of exactly how to indent or dedent is not up for discussion — if there are good reasons to disagree with textwrap now's the time to bring it up.)
I don’t know if it’s a good reason, but I’m of the opinion that the required backslash at the beginning of to-be-dedented string is strange:
We try to eliminate escaped newlines elsewhere (e.g. bracing import statements, conditions and tuple values is preferred to escaping newlines)
I think dedent (or however it’s going to be called) should remove common whitespace and, if the first line is completely empty, that first line as well.
Also for your consideration would be scala’s way:
"""|spam |eggs""".stripMargin() =="spam\neggs"
"""#spam #eggs""".stripMargin('#') =="spam\neggs"
i.e. removal of all leading whitespace up to and including a margin character/prefix. It could be a kwarg to “dedent”…
Or strip the common indent, and the initial empty line if present, and optionally add an indent: """ spam eggs """.reindent() == "spam\neggs\n" """ spam eggs """.reindent(4) == " spam\n eggs\n"
On Mon, Jul 01, 2013 at 06:22:25PM +0200, Philipp A. wrote:
2013/7/1 Guido van Rossum guido@python.org
That‘s a compelling argument. Let’s do it. (Assuming the definition of exactly how to indent or dedent is not up for discussion — if there are good reasons to disagree with textwrap now's the time to bring it up.)
I don’t know if it’s a good reason, but I’m of the opinion that the required backslash at the beginning of to-be-dedented string is strange:
It's not *required*. It's optional. You can live with an extra blank line: s = """ first line second line ... """ or you can manually indent the first line: s = """ first line second line ... """ or you can slice the string before calling dedent, or, in my opinion the neatest and best solution, just escape the opening newline with a backslash: s = """\ first line second line ... """ But in any case, I don't like the idea of making the proposed dedent method be a DWIM "format strings the way I want them to be formatted" method. It's called "dedent", not "dedent and strip leading newlines". I'm okay in principle with dedent taking additional arguments to customize the behaviour, such as amount of whitespace to keep or a margin character, so long as the default with no args matches textwrap.dedent. -- Steven
On 2013-07-02 03:04, Steven D'Aprano wrote:
On Mon, Jul 01, 2013 at 06:22:25PM +0200, Philipp A. wrote:
2013/7/1 Guido van Rossum guido@python.org
That‘s a compelling argument. Let’s do it. (Assuming the definition of exactly how to indent or dedent is not up for discussion — if there are good reasons to disagree with textwrap now's the time to bring it up.)
I don’t know if it’s a good reason, but I’m of the opinion that the required backslash at the beginning of to-be-dedented string is strange:
It's not *required*. It's optional. You can live with an extra blank line:
s = """ first line second line ... """
or you can manually indent the first line:
s = """ first line second line ... """
or you can slice the string before calling dedent, or, in my opinion the neatest and best solution, just escape the opening newline with a backslash:
s = """\ first line second line ... """
But in any case, I don't like the idea of making the proposed dedent method be a DWIM "format strings the way I want them to be formatted" method. It's called "dedent", not "dedent and strip leading newlines".
I'm okay in principle with dedent taking additional arguments to customize the behaviour, such as amount of whitespace to keep or a margin character, so long as the default with no args matches textwrap.dedent.
How about an option to ignore the first line? -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
On 07/02/2013 05:32 AM, Robert Kern wrote:
s = """\ first line second line ... """
But in any case, I don't like the idea of making the proposed dedent method be a DWIM "format strings the way I want them to be formatted" method. It's called "dedent", not "dedent and strip leading newlines".
I'm okay in principle with dedent taking additional arguments to customize the behaviour, such as amount of whitespace to keep or a margin character, so long as the default with no args matches textwrap.dedent.
How about an option to ignore the first line?
A method that only adjusts leading space should only do that. I wrote a function to split a text string into paragraphs, and I found that it made sense for that to strip leading space and trailing white space. The reason is, it is not clear if the leading or trailing white space is an empty paragraph or not. If you treat those as empty paragraphs at the beginning and end, then you end up with too much white space when you join them back together after re-flowing the paragraphs. It seems the wrap and fill functions in textwrap have some issues too. There is an issue on the bug tracker, but the exact nature of the problems and weather or not anyone is depending on the current behavior. The textwrap module, doesn't remove extra white space inside the string, but only does a strip, removing leading and trailing white space. So leading white space on lines gets folded into the reflowed text. That can't be what was originally intended. from textwrap import * s = """ This is a multi-line string that has no meaningful formatting, to see what fill and wrap do to it. """ print('"""' + fill(s) + '"""') """ This is a multi-line string that has no meaningful formatting, to see what fill and wrap do to it.""" print for x in wrap(s, 40): print('"""'+x+'"""') """ This is a multi-line string that has no meaningful formatting, to see what fill and wrap do to it.""" """ This is a multi-line string""" """that has no""" """meaningful formatting, to see what""" """fill and wrap do to it.""" Cheers, Ron
Ooops,, please pardon the few too many editing glitches due to not yet being fully awake. Getting that second cup of coffee, Ron
I wanted to make sure the text I was posting was being rendered in fixed width font, hence the gist. On Sunday, June 30, 2013 6:47:29 PM UTC-7, Nick Coghlan wrote:
On 1 July 2013 11:09, Steven D'Aprano <st...@pearwood.info <javascript:>> wrote:
but in either case, I think the choice of --- as delimiter is ugly and arbitrary, and very likely is ambiguous (currently, x = ---1 is legal code). Similar suggestions to this have been made many times before, you should search the archives:
I'm still partial to the idea of offering textwrap.indent() and textwrap.dedent() as string methods.
1. You could add a ".dedent()" at the end of a triple quoted string for this kind of problem. For a lot of code, the runtime cost isn't an issue. 2. A JIT would definitely be able to avoid recalculating the result every time 3. Even CPython may eventually gain constant folding for that kind of method applied directly to a string literal 4. I dedent and indent long strings more often than I capitalize, center, tab expand, or perform various other operations which already grace the str type as methods.
Cheers, Nick.
-- Nick Coghlan | ncog...@gmail.com <javascript:> | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python...@python.org <javascript:> http://mail.python.org/mailman/listinfo/python-ideas
I think this could cause problems with multi-line strings that contain additional indentation: def get_yaml(): x = """ foo: Bar user: fname: Hans lname: Gans """.dedent() return x While i don't see many arguments why somebody would want to store configuration files inside a string, i am sure many beginners who try to use this method will be surprised by its behavior. -- Markus On Mon, Jul 01, 2013 at 11:47:29AM +1000, Nick Coghlan wrote:
On 1 July 2013 11:09, Steven D'Aprano <steve@pearwood.info> wrote:
but in either case, I think the choice of --- as delimiter is ugly and arbitrary, and very likely is ambiguous (currently, x = ---1 is legal code). Similar suggestions to this have been made many times before, you should search the archives:
I'm still partial to the idea of offering textwrap.indent() and textwrap.dedent() as string methods.
1. You could add a ".dedent()" at the end of a triple quoted string for this kind of problem. For a lot of code, the runtime cost isn't an issue. 2. A JIT would definitely be able to avoid recalculating the result every time 3. Even CPython may eventually gain constant folding for that kind of method applied directly to a string literal 4. I dedent and indent long strings more often than I capitalize, center, tab expand, or perform various other operations which already grace the str type as methods.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
Have you tried using textwrap.dedent with this string? It gives what I think is the expected result: '\nfoo: Bar\nuser:\n fname: Hans\n lname: Gans\n' since it only removes common leading whitespace. On Mon, Jul 1, 2013 at 1:50 AM, Markus Unterwaditzer < markus@unterwaditzer.net> wrote:
I think this could cause problems with multi-line strings that contain additional indentation:
def get_yaml(): x = """ foo: Bar user: fname: Hans lname: Gans """.dedent() return x
While i don't see many arguments why somebody would want to store configuration files inside a string, i am sure many beginners who try to use this method will be surprised by its behavior.
-- Markus
On Mon, Jul 01, 2013 at 11:47:29AM +1000, Nick Coghlan wrote:
On 1 July 2013 11:09, Steven D'Aprano <steve@pearwood.info> wrote:
but in either case, I think the choice of --- as delimiter is ugly and arbitrary, and very likely is ambiguous (currently, x = ---1 is legal code). Similar suggestions to this have been made many times before, you should search the archives:
I'm still partial to the idea of offering textwrap.indent() and textwrap.dedent() as string methods.
1. You could add a ".dedent()" at the end of a triple quoted string for this kind of problem. For a lot of code, the runtime cost isn't an issue. 2. A JIT would definitely be able to avoid recalculating the result every time 3. Even CPython may eventually gain constant folding for that kind of method applied directly to a string literal 4. I dedent and indent long strings more often than I capitalize, center, tab expand, or perform various other operations which already grace the str type as methods.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
Thanks for pointing it out, i have to admit that i didn't read the documentation carefully, and yes, that indeed makes my example invalid, but then there are still strings that have indentation on all lines, which would be completely trunchated with dedent(). -- Markus (from phone) Daniel Robinson <gottagetmac@gmail.com> wrote:
Have you tried using textwrap.dedent with this string? It gives what I think is the expected result:
'\nfoo: Bar\nuser:\n fname: Hans\n lname: Gans\n'
since it only removes common leading whitespace.
On Mon, Jul 1, 2013 at 1:50 AM, Markus Unterwaditzer < markus@unterwaditzer.net> wrote:
I think this could cause problems with multi-line strings that contain additional indentation:
def get_yaml(): x = """ foo: Bar user: fname: Hans lname: Gans """.dedent() return x
While i don't see many arguments why somebody would want to store configuration files inside a string, i am sure many beginners who try to use this method will be surprised by its behavior.
-- Markus
On Mon, Jul 01, 2013 at 11:47:29AM +1000, Nick Coghlan wrote:
On 1 July 2013 11:09, Steven D'Aprano <steve@pearwood.info> wrote:
but in either case, I think the choice of --- as delimiter is ugly and arbitrary, and very likely is ambiguous (currently, x = ---1 is legal code). Similar suggestions to this have been made many times before, you should search the archives:
I'm still partial to the idea of offering textwrap.indent() and textwrap.dedent() as string methods.
1. You could add a ".dedent()" at the end of a triple quoted string for this kind of problem. For a lot of code, the runtime cost isn't an issue. 2. A JIT would definitely be able to avoid recalculating the result every time 3. Even CPython may eventually gain constant folding for that kind of method applied directly to a string literal 4. I dedent and indent long strings more often than I capitalize, center, tab expand, or perform various other operations which already grace the str type as methods.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
Thanks for pointing it out, i have to admit that i didn't read the documentation carefully, and yes, that indeed makes my example invalid, but
On 1 July 2013 16:23, Markus Unterwaditzer <markus@unterwaditzer.net> wrote: then there are still strings that have indentation on all lines, which would be completely trunchated with dedent(). If you call a function or method that has the purpose of stripping common leading whitespace, stripping common leading whitespace is hardly a surprising outcome. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
I realize how unclear i've been. What i am asking for is to have a way to handle strings like this: def foo(): return """ look at me i am cool i can do indentation\n""" I rather want to write code that looks a lot more like this: def foo(): return """ look at me i am cool i can do indentation """ So the first line would have four spaces at the beginning, the second eight, the third four again. The "\n" character after "indentation" would be the last character in the string. With a new string method i would probably try this: def foo(): """ look at me i am cool i can do indentation """.dedent() But, by this string method behaving like textwrap.dedent, this would also remove the first four spaces of each line, which is not the behavior i wanted. -- Markus On Mon, Jul 01, 2013 at 08:23:26AM +0200, Markus Unterwaditzer wrote:
Thanks for pointing it out, i have to admit that i didn't read the documentation carefully, and yes, that indeed makes my example invalid, but then there are still strings that have indentation on all lines, which would be completely trunchated with dedent().
-- Markus (from phone)
Daniel Robinson <gottagetmac@gmail.com> wrote:
Have you tried using textwrap.dedent with this string? It gives what I think is the expected result:
'\nfoo: Bar\nuser:\n fname: Hans\n lname: Gans\n'
since it only removes common leading whitespace.
On Mon, Jul 1, 2013 at 1:50 AM, Markus Unterwaditzer < markus@unterwaditzer.net> wrote:
I think this could cause problems with multi-line strings that contain additional indentation:
def get_yaml(): x = """ foo: Bar user: fname: Hans lname: Gans """.dedent() return x
While i don't see many arguments why somebody would want to store configuration files inside a string, i am sure many beginners who try to use this method will be surprised by its behavior.
-- Markus
On Mon, Jul 01, 2013 at 11:47:29AM +1000, Nick Coghlan wrote:
On 1 July 2013 11:09, Steven D'Aprano <steve@pearwood.info> wrote:
but in either case, I think the choice of --- as delimiter is ugly and arbitrary, and very likely is ambiguous (currently, x = ---1 is legal code). Similar suggestions to this have been made many times before, you should search the archives:
I'm still partial to the idea of offering textwrap.indent() and textwrap.dedent() as string methods.
1. You could add a ".dedent()" at the end of a triple quoted string for this kind of problem. For a lot of code, the runtime cost isn't an issue. 2. A JIT would definitely be able to avoid recalculating the result every time 3. Even CPython may eventually gain constant folding for that kind of method applied directly to a string literal 4. I dedent and indent long strings more often than I capitalize, center, tab expand, or perform various other operations which already grace the str type as methods.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
On 07/01/2013 05:52 AM, Markus Unterwaditzer wrote:
I rather want to write code that looks a lot more like this:
def foo(): return """ look at me i am cool i can do indentation """
So the first line would have four spaces at the beginning, the second eight, the third four again. The "\n" character after "indentation" would be the last character in the string.
Currently to get what you want you need to use both dedent and indent.
print(indent(dedent(""" ... look at me ... I am cool ... I can do indentation ... """), prefix=" "))
look at me I am cool I can do indentation Since indent is already in textwrap and works differently, I think 'margin' would be a good method name to set the left margin. def foo(): return """\ look at me i am cool i can do dedent. """.margin(4) I think this fits a much more common usage pattern, and we won't need to add two methods to do what you want here. A dedent method could take a 'margin' argument.. s.dedent(margin=4) But I prefer just calling it margin. Cheers, Ron
01.07.13 04:47, Nick Coghlan написав(ла):
4. I dedent and indent long strings more often than I capitalize, center, tab expand, or perform various other operations which already grace the str type as methods.
The str type already has many rarely used methods, so let's add a couple more. It doesn't look good argument.
On 1 Jul 2013 20:01, "Serhiy Storchaka" <storchaka@gmail.com> wrote:
01.07.13 04:47, Nick Coghlan написав(ла):
4. I dedent and indent long strings more often than I capitalize, center, tab expand, or perform various other operations which already grace the str type as methods.
The str type already has many rarely used methods, so let's add a couple
more. It doesn't look good argument. I almost left that point out, as I kinda feel the same way. OTOH, I want indent pretty much every time I write a script that invokes other command line tools, and I'm serious about the possibility of having the compiler implicitly dedent docstrings once the method support exists to make it practical. Cheers, Nick.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
Le Mon, 1 Jul 2013 20:16:02 +1000, Nick Coghlan <ncoghlan@gmail.com> a écrit :
On 1 Jul 2013 20:01, "Serhiy Storchaka" <storchaka@gmail.com> wrote:
01.07.13 04:47, Nick Coghlan написав(ла):
4. I dedent and indent long strings more often than I capitalize, center, tab expand, or perform various other operations which already grace the str type as methods.
The str type already has many rarely used methods, so let's add a couple
more. It doesn't look good argument.
I almost left that point out, as I kinda feel the same way. OTOH, I want indent pretty much every time I write a script that invokes other command line tools, and I'm serious about the possibility of having the compiler implicitly dedent docstrings once the method support exists to make it practical.
I think dedent() is quite useful too. OTOH, I don't think there's much point in indent() as a str method (except for consistency). Also, indent() may want more options and knobs than dedent() has, and therefore would be better implemented in pure Python. Regards Antoine.
On Jun 30, 2013, at 18:09, Steven D'Aprano <steve@pearwood.info> wrote:
Hi nbv4, and welcome.
On 01/07/13 10:32, nbv4 wrote:
The tripple quote string literal is a great feature, but there is one problem. When you use them, it forces you to break out of you're current indentation which maks code look ugly. I propose a new way to define a triple back quote that woks the same way regular triple quotes work, but instead does some simple parsing of the data within the quotes to preserve the flow of the code. Due to the brittle and sometimes ambigious nature of anything 'automatic', this feature is obviously not meant for data where exact white space is needed. It would be great for docstrings, exception messages and other type text.
Here is a short example of it's usage: https://gist.github.com/priestc/5897602
For something as trivial as the example you give, there is no need to send people off to a website, which they may not have access too. Here's the simplified version:
# Proposed syntax def func(): s = """line 1 line 2 line 3""" t = ---line 1 line 2 line 3--- return s, t
The difference being, lines 2 and 3 of s will begin with four spaces, while t reduces the whitespace between lines to a single space:
s == 'line 1\n line 2\n line 3' t == 'line 1 line 2 line 3'
I don't think this is particularly useful. I would be more interested in it if it kept the newlines but got rid of the leading spaces:
t == 'line 1\nline 2\nline 3'
but in either case, I think the choice of --- as delimiter is ugly and arbitrary, and very likely is ambiguous (currently, x = ---1 is legal code).
The proposal used backticks, not hyphens: print ``` Now my code looks much better. The output of this function is as if you had written it in the same way its written in the code above, except with all newlines replaced with spaces and big swaths of spaces removed. ``` So, both the ambiguity and a lot of the ugliness you complain about aren't in the proposal at all. That being said, I don't really like the proposal, and at least half of the alternatives suggested last time this came up a few months ago were better.
On 01/07/13 12:14, Andrew Barnert wrote:
On Jun 30, 2013, at 18:09, Steven D'Aprano <steve@pearwood.info> wrote:
Hi nbv4, and welcome.
On 01/07/13 10:32, nbv4 wrote:
Here is a short example of it's usage: https://gist.github.com/priestc/5897602 [...]
The proposal used backticks, not hyphens:
Wow, that's weird. They look exactly like hyphens in my browser. -- Steven
+1 for just offering .dedent() on strings. On Mon, Jul 1, 2013 at 10:28 AM, Steven D'Aprano <steve@pearwood.info>wrote:
On 01/07/13 12:14, Andrew Barnert wrote:
On Jun 30, 2013, at 18:09, Steven D'Aprano <steve@pearwood.info> wrote:
Hi nbv4, and welcome.
On 01/07/13 10:32, nbv4 wrote:
Here is a short example of it's usage:
https://gist.github.com/**priestc/5897602<https://gist.github.com/priestc/5897602>
[...]
The proposal used backticks, not hyphens:
Wow, that's weird. They look exactly like hyphens in my browser.
-- Steven ______________________________**_________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/**mailman/listinfo/python-ideas<http://mail.python.org/mailman/listinfo/python-ideas>
"dedent" is a weird word, maybe "unindent" would be better? On Sunday, June 30, 2013 7:35:37 PM UTC-7, Haoyi Li wrote:
+1 for just offering .dedent() on strings.
On Mon, Jul 1, 2013 at 10:28 AM, Steven D'Aprano <st...@pearwood.info<javascript:>
wrote:
On 01/07/13 12:14, Andrew Barnert wrote:
On Jun 30, 2013, at 18:09, Steven D'Aprano <st...@pearwood.info<javascript:>> wrote:
Hi nbv4, and welcome.
On 01/07/13 10:32, nbv4 wrote:
Here is a short example of it's usage:
https://gist.github.com/**priestc/5897602<https://gist.github.com/priestc/5897602>
[...]
The proposal used backticks, not hyphens:
Wow, that's weird. They look exactly like hyphens in my browser.
-- Steven ______________________________**_________________ Python-ideas mailing list Python...@python.org <javascript:> http://mail.python.org/**mailman/listinfo/python-ideas<http://mail.python.org/mailman/listinfo/python-ideas>
nbv4 <nbvfour@gmail.com> writes:
"dedent" is a weird word, maybe "unindent" would be better?
That ship has sailed, since the name “dedent” is already established usage in Python (from ‘textwrap.deden in the standard libraryt’). A better term, by symmetry with “indent”, would have been “outdent” <URL:https://en.wiktionary.org/wiki/outdent>. But that would be needlessly confusing since we already refer to it in Python by the neologism “dedent”. -- \ “I love to go down to the schoolyard and watch all the little | `\ children jump up and down and run around yelling and screaming. | _o__) They don't know I'm only using blanks.” —Emo Philips | Ben Finney
Maybe "dedent" should be replaced with "outdent", while keeping the old names for compatibility. On Sun, Jun 30, 2013 at 11:19 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
nbv4 <nbvfour@gmail.com> writes:
"dedent" is a weird word, maybe "unindent" would be better?
That ship has sailed, since the name “dedent” is already established usage in Python (from ‘textwrap.deden in the standard libraryt’).
A better term, by symmetry with “indent”, would have been “outdent” <URL:https://en.wiktionary.org/wiki/outdent>. But that would be needlessly confusing since we already refer to it in Python by the neologism “dedent”.
-- \ “I love to go down to the schoolyard and watch all the little | `\ children jump up and down and run around yelling and screaming. | _o__) They don't know I'm only using blanks.” —Emo Philips | Ben Finney
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
Maybe "dedent" should be replaced with "outdent", while keeping the old names for compatibility. SpaghettiToastBook On Mon, Jul 1, 2013 at 3:13 AM, SpaghettiToastBook . <spaghettitoastbook@gmail.com> wrote:
Maybe "dedent" should be replaced with "outdent", while keeping the old names for compatibility.
On Sun, Jun 30, 2013 at 11:19 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
nbv4 <nbvfour@gmail.com> writes:
"dedent" is a weird word, maybe "unindent" would be better?
That ship has sailed, since the name “dedent” is already established usage in Python (from ‘textwrap.deden in the standard libraryt’).
A better term, by symmetry with “indent”, would have been “outdent” <URL:https://en.wiktionary.org/wiki/outdent>. But that would be needlessly confusing since we already refer to it in Python by the neologism “dedent”.
-- \ “I love to go down to the schoolyard and watch all the little | `\ children jump up and down and run around yelling and screaming. | _o__) They don't know I'm only using blanks.” —Emo Philips | Ben Finney
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
On 01/07/13 12:49, nbv4 wrote:
"dedent" is a weird word, maybe "unindent" would be better?
The de- prefix is a standard English prefix meaning removal, negation or reversal: http://dictionary.reference.com/browse/de- Neologism or not, I think that dedent is sufficiently understandable and widespread that there's no need to deprecate it in favour of "outdent". It's being used in the F# and Ruby communities, as well as Python: http://en.wiktionary.org/wiki/dedent https://github.com/cespare/ruby-dedent -- Steven
On 07/01/2013 03:12 PM, Steven D'Aprano wrote:
"dedent" is a weird word, maybe "unindent" would be better?
The de- prefix is a standard English prefix meaning removal, negation or reversal:
http://dictionary.reference.com/browse/de-
Neologism or not, I think that dedent is sufficiently understandable and widespread that there's no need to deprecate it in favour of "outdent". It's being used in the F# and Ruby communities, as well as Python:
Hi all, this is my first message here :) I use Python since almost 7 years, and I discovered textwrap.dedent() right now, by following this thread. So in my case if yesterday I had seen there was a method str.dedent(), I should have looked at the documentation to know its meaning, but if I had seen str.unindent(), I shouldn't have looked at the doc at all, because the meaning appears to me very clear. Maybe this comes either from my poor English or from my lacks in Python (or both...), but maybe not, because looking for "unindent indentation" , "dedent indentation" or "deindent indentation" on Google, we can see people use the word "unindent" and not dedent or deindent. + 1 for unindent() http://en.wiktionary.org/wiki/unindent -- Marco Buttu INAF Osservatorio Astronomico di Cagliari Loc. Poggio dei Pini, Strada 54 - 09012 Capoterra (CA) - Italy Phone: +39 070 71180255 Email: mbuttu@oa-cagliari.inaf.it
On 13 July 2013 11:45, Marco Buttu <mbuttu@oa-cagliari.inaf.it> wrote:
On 07/01/2013 03:12 PM, Steven D'Aprano wrote:
"dedent" is a weird word, maybe "unindent" would be better?
The de- prefix is a standard English prefix meaning removal, negation or reversal:
http://dictionary.reference.**com/browse/de-<http://dictionary.reference.com/browse/de->
Neologism or not, I think that dedent is sufficiently understandable and widespread that there's no need to deprecate it in favour of "outdent". It's being used in the F# and Ruby communities, as well as Python:
http://en.wiktionary.org/wiki/**dedent<http://en.wiktionary.org/wiki/dedent>
https://github.com/cespare/**ruby-dedent<https://github.com/cespare/ruby-dedent>
Hi all, this is my first message here :) I use Python since almost 7 years, and I discovered textwrap.dedent() right now, by following this thread. So in my case if yesterday I had seen there was a method str.dedent(), I should have looked at the documentation to know its meaning, but if I had seen str.unindent(), I shouldn't have looked at the doc at all, because the meaning appears to me very clear. Maybe this comes either from my poor English or from my lacks in Python (or both...), but maybe not, because looking for "unindent indentation" , "dedent indentation" or "deindent indentation" on Google, we can see people use the word "unindent" and not dedent or deindent.
+ 1 for unindent()
http://en.wiktionary.org/wiki/**unindent<http://en.wiktionary.org/wiki/unindent>
Interestingly dedent has an entry on wiktionary, with a note that its primary use is Python: http://en.wiktionary.org/wiki/dedent So whilst the meaning is obvious to native speakers, it can hardly be said to be a term in common usage. (The wiktionary entry suggests it is a synonym for "outdent".) Michael
-- Marco Buttu
INAF Osservatorio Astronomico di Cagliari Loc. Poggio dei Pini, Strada 54 - 09012 Capoterra (CA) - Italy Phone: +39 070 71180255 Email: mbuttu@oa-cagliari.inaf.it
______________________________**_________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/**mailman/listinfo/python-ideas<http://mail.python.org/mailman/listinfo/python-ideas>
-- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html
On 07/13/2013 11:40 AM, Michael Foord wrote:
I use Python since almost 7 years, and I discovered textwrap.dedent() right now, by following this thread. So in my case if yesterday I had seen there was a method str.dedent(), I should have looked at the documentation to know its meaning, but if I had seen str.unindent(), I shouldn't have looked at the doc at all, because the meaning appears to me very clear. Maybe this comes either from my poor English or from my lacks in Python (or both...), but maybe not, because looking for "unindent indentation" , "dedent indentation" or "deindent indentation" on Google, we can see people use the word "unindent" and not dedent or deindent.
+ 1 for unindent()
http://en.wiktionary.org/wiki/unindent
Interestingly dedent has an entry on wiktionary, with a note that its primary use is Python:
http://en.wiktionary.org/wiki/dedent
So whilst the meaning is obvious to native speakers, it can hardly be said to be a term in common usage. (The wiktionary entry suggests it is a synonym for "outdent".)
Michael
And by the way, Python itself prefers to use unindent: >>> def foo(): ... """foo""" ... pass File "<stdin>", line 3 pass ^ IndentationError: unindent does not match any outer indentation level -- Marco Buttu INAF Osservatorio Astronomico di Cagliari Loc. Poggio dei Pini, Strada 54 - 09012 Capoterra (CA) - Italy Phone: +39 070 71180255 Email: mbuttu@oa-cagliari.inaf.it
nbv4 <nbvfour@gmail.com> writes:
The tripple quote string literal is a great feature, but there is one problem. When you use them, it forces you to break out of you're current indentation which maks code look ugly.
We have the ‘textwrap.dedent’ function in the standard library. Here is a StackOverflow answer that shows how it is used for exactly the situation you describe <URL:http://stackoverflow.com/a/2504454/70157>.
I propose a new way to define a triple back quote that woks the same way regular triple quotes work, but instead does some simple parsing of the data within the quotes to preserve the flow of the code.
−1. This problem already has a standard-library solution, it is not common enough to need a change to the language syntax. If anything, a ‘dedent’ method on strings would be good. But not adding more complexities to syntax for this, please. -- \ “Following fashion and the status quo is easy. Thinking about | `\ your users' lives and creating something practical is much | _o__) harder.” —Ryan Singer, 2008-07-09 | Ben Finney
participants (21)
-
Andrew Barnert -
Antoine Pitrou -
Ben Finney -
chris priest -
Daniel Robinson -
Guido van Rossum -
Haoyi Li -
Joshua Landau -
Marco Buttu -
Markus Unterwaditzer -
Michael Foord -
MRAB -
nbv4
-
Nick Coghlan -
Philipp A. -
Robert Kern -
Ron Adam -
Serhiy Storchaka -
SpaghettiToastBook . -
Steven D'Aprano -
Terry Reedy