Uzume added the comment:
Many have chimed in on this topic but I thought I would lend my stance--for
whatever it is worth.
I also believe most of these do not fit concept of a character codec and some
sort of transforms would likely be useful, however most are sort of specialized
(e.g., there should probably be a generalized compression library interface al
la hashlib):
rot13: a (albeit simplistic) text cipher (str to str; though bytes to bytes
could be argued since since many crypto functions do that)
zlib, bz2, etc. (lzma/xz should also be here): all bytes to bytes compression
transforms
hex(adecimal) uu, base64, etc.: these more or less fit the description of a
character codec as they map between bytes and str, however, I am not sure they
are really the same thing as these are basically doing a radix transformation
to character symbols and the mapping it not strictly from bytes to a single
character and back as a true character codec seems to imply. As evidenced by by
int() format() and bytes.fromhex(), float.hex(), float.fromhex(), etc., these
are more generalized conversions for serializing strings of bits into a textual
representation (possibly for human consumption).
I personally feel any type/class.hex(), etc. method would be better off as a
format() style formatter if they are to exist in such a space at all (i.e., not
some more generalized conversion library--which we have but since 3.x could
probably use to be updated and cleaned up).
--
nosy: +uzume
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7475
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
