Raymond Hettinger wrote:
That is somewhat misleading. We already have that ability. What is being proposed is moving existing code to a different namespace. So the motivation is really something like:
I want to write s = s.dedent() because it is too painful to write s = textwrap.dedent(s)
From technical point of view, there is nothing wrong with placing this functionality in textwrap. But from usability point of view using textwrap.dedent is like importing some stuff for doing string concatenation or integer addition.
In textwrap module this function placed in section "Loosely (!) related functionality". When Python beginner try to find "Pythonic" way for dealing with dedenting (And she know, in Python "there should be one -- and preferably only one -- obvious way to do it"), it is very unlikely that she think "Which module may contain standard string dedenting? Yes, of course textwrap! I'm sure I'll find necessary function there!"
String methods should be limited to generic string manipulations. String applications should be in other namespaces. That is why we don't have str.md5(), str.crc32(), str.ziplib(), etc.
I think, dedenting must be classified as "generic string manipulations". The need in string dedenting results from meaningful indentation and widespread use of text editors with folding support. Multiline strings without leading whitespaces breaks correct folding in some editors. Best regards, Alexander mailto:kozlovsky@mail.spbnit.ru