Gareth McCaughan wrote:
On Sunday 2005-11-13 17:43, Marc-Andre Lemburg wrote:
The idea is to add a method called "dedent" to strings. It would do exactly what the current textwrap.indent function does.
You are missing a point here: string methods were introduced to make switching from plain 8-bit strings to Unicode easier.
As such they are only needed in cases where an algorithm has to work on the resp. internals differently or where direct access to the internals makes a huge difference in terms of performance.
In a language that generally pays as much attention to practical usability as Python, it seems a pity to say (as you seem to be implying) that whether something is a string method or a function in (say) the "textwrap" module should be determined by internal implementation details.
We have to draw a line somewhere - otherwise you could just as well add all functions that accept single string arguments as methods to the basestring sub-classes.
Writing multilined strings without spaces in the beginning of lines makes functions harder to read, since although the Python parser is happy with it, it breaks the visual indentation.
This is really a minor compiler/parser issue and not one which warrants adding another string method.
Adding another string method seems easier, and a smaller change, than altering the compiler or parser. What's your point here? I think I must be missing something.
The point is that the presented use case does not originate in a common need (to dedent strings), but from a desire to write Python code with embedded indented triple-quoted strings which lies in the scope of the parser, not that of string objects.