why the string function / module change

[David Bolen]

Sean 'Shaleh' Perry <shaleh at valinux.com> writes:

> Ok, so I read the what's new.  I understand that for Unicode support the
> string module needed help.  No problem.  By why introduce a new syntax that
> makes 2.0 incompatible with 1.5?

The syntax change wasn't to support Unicode, it was to make string
methods actual methods of string objects, and thus more consistent
with other Python objects.

If you think about, the string module was the odd man out.  After all,
if you want to read or write to a file object, you use
<fileobj>.read() and <fileobj>.write().  You don't use
filemodule.read(<fileobj>) and filemodule.write(<fileobj>).

If you are appending to a list object you use <listobj>.append(), and
not listmodule.append(<listobj>).  Similarly with dictionaries, and so on...

The string module - I expect largely for legacy reasons - existed as a
module with functions that took string objects as parameters.  But
that's very different than methods right on the string objects, which
are much more consistent with other objects in Python.

> split(foo) worked just as well.  I understand there were problems making the
> string module do this, but still.  Could they have not been _split() or
> something to dissuade their use?

I'm not aware of any problems - and you can still use
"string.split(foo)" rather than "foo.split()" if you like (internally
the string module functions are just reflected through the methods on
the objects they are given).   Although its possible that the string
module may eventually be deprecated, it's not likely to be for quite a
while, if ever.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/