[Python-Dev] bytes.from_hex() [Was: PEP 332 revival in coordination with pep 349?] (original) (raw)

M.-A. Lemburg mal at egenix.com
Fri Feb 17 14:30:14 CET 2006

Martin v. Löwis wrote:

Josiah Carlson wrote:

I would agree that zip is questionable, but 'uu', 'rot13', perhaps 'hex', and likely a few others that the two of you may be arguing against should stay as encodings, because strictly speaking, they are defined as encodings of data. They may not be encodings of unicode data, but that doesn't mean that they aren't useful encodings for other kinds of data, some text, some binary, ... To support them, the bytes type would have to gain a .encode method, and I'm -1 on supporting bytes.encode, or string.decode. Why is s.encode("uu") any better than binascii.b2auu(s)

The .encode() and .decode() methods are merely convenience interfaces to the registered codecs (with some extra logic to make sure that only a pre-defined set of return types are allowed). It's up to the user to use them for e.g. UU-encoding or not.

The reason we have codecs for UU, zip and the others is that you can use their StreamWriters/Readers in stackable streams.

Just because some codecs don't fit into the string.decode() or bytes.encode() scenario doesn't mean that these codecs are useless or that the methods should be banned.

-- Marc-Andre Lemburg eGenix.com

Professional Python Services directly from the Source (#1, Feb 17 2006)

Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

More information about the Python-Dev mailing list