[Python-Dev] Optional arguments for str.encode /.decode

Martin v. Löwis martin at v.loewis.de
Sat Nov 8 15:39:06 EST 2003


"Raymond Hettinger" <python at rcn.com> writes:

> I understand a desire to keep it pure.  Would it be useful to add a
> separate method to support non-Unicode access?

No.

> This style of access has some wonderful properties in terms of
> decoupling, accessibility, learnability, and uniformity.

No. The .encode approach you are talking about requires users to put
string literals into Python source. This is
a) completely different from encoding, where you learn the encoding
   only at run-time, e.g. from a MIME header or a config file.
b) creates a different way to do the same thing;
There should be one-- and preferably only one --obvious way to do it.

> t.transform('crc32')

Better write this as

crc32.transform(t)

> t.transform('md5')

Better md5.transform(t)

> t.transform('des_encode', key=0x10ab03b78495d2)

Better des.encrypt(t, key=0x10ab03b78495d2). For des, there are two
operations for string conversion, encrypt and decrypt; putting the
direction of the operation in the transform name sux.

> t.transform('substitution', name='guido', home='netherlands')

Better

t.substitute(name='guido', home='netherlands')

> t.transform('huffman')

Better huffman.transform(t)

They are *not* uniform, as you have to remember the various
parameters.

Regards,
Martin



More information about the Python-Dev mailing list