On 11/14/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > 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.
Please read my first post in this thread - I think there's more reason for 'dedent' to be a string method than there is, for example, for 'expandtabs', since it allows you to write clearer code. > > 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. > That's a theoretical argument. In practice, if you do it in the parser, you have two options: 1. Automatically dedent all strings. 2. Add a 'd' or some other letter before the string. Option 1 breaks backwards compatibility, and makes the parser do unexpected things. Option 2 adds another string-prefix letter, which is confusing, and it will also be hard to find out what that letter means. On the other hand, adding ".dedent()" at the end is very clear, and is just as easy. Now, about performance, please see the message I'll post in a few minutes... Noam _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
