"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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4