On 1 July 2013 11:57, Guido van Rossum
On Sun, Jun 30, 2013 at 6:47 PM, Nick Coghlan
wrote: On 1 July 2013 11:09, Steven D'Aprano
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