kozlovsky at mail.spbnit.ru
Sun Nov 13 14:57:40 CET 2005
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.
Alexander mailto:kozlovsky at mail.spbnit.ru
More information about the Python-Dev