noamraph at gmail.com
Mon Nov 14 20:33:13 CET 2005
Just two additional notes:
On 9/15/05, Raymond Hettinger <raymond.hettinger at verizon.net> wrote:
> Let it continue to live in textwrap where the existing pure python code
> adequately serves all string-like objects. It's not worth losing the
> duck typing by attaching new methods to str, unicode, UserString, and
> everything else aspiring to be string-like.
It may seem like the 'dedent' code would have to be written a lot of
times, but I've checked the examples. It may be needed to write
different versions for 'str' and for 'unicode', but these are going to
be unified. In UserString you'll have to add exactly one line:
def dedent(self): return self.data.dedent()
I've just taken the line created for 'isalpha' and replaced 'isalpha'
with 'dedent'. So in the long run, there will be exactly one
implementation of 'dedent' in the Python code. (I don't know of any
other objects which try to provide the full string interface.)
Another reason for prefering a 'dedent' method over a 'dedent'
function in some module, is that it allows sometime in the future to
add an optimization to the compiler, so that it will dedent the string
in compile time (this can't work for a function, since the function is
found in run time). This will solve the performance problem
completely, so that there will be an easy way to write multilined
strings which do not interfere with the visual structure of the code,
without the need to worry about performance. I'm not saying that this
optimization has to be done now, just that 'dedent' as a method makes
it possible, which adds to the other arguments for making it a method.
More information about the Python-Dev