Nick Coghlan wrote:
> ascii_bytes = orig_bytes.decode("base64").encode("ascii")
>
> orig_bytes = ascii_bytes.decode("ascii").encode("base64")
>
> The only slightly odd aspect is that this inverts the conventional meaning of
> base64 encoding and decoding,
-1. Whatever we do, we shouldn't design things so
that it's necessary to write anything as
unintuitive as that.
We need to make up our minds whether the .encode()
and .decode() methods are only meant for Unicode
encodings, or whether they are for general
transformations between bytes and characters.
If they're only meant for Unicode, then bytes
should only have .decode(), unicode strings
should only have .encode(), and only Unicode
codecs should be available that way. Things
like base64 would need to have a different
interface.
If they're for general transformations, then
both types should have both methods, with the
return type depending on the codec you're
using, and it's the programmer's responsibility
to use codecs that make sense for what he's
doing.
But if they're for general transformations,
why limit them to just bytes and characters?
Following that through leads to giving *every*
object .encode() and .decode() methods. I
don't think we should go that far, but it's
hard to see where to draw the line. Are
bytes and strings special enough to justify
them having their own peculiar methods for
codec access?
--
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand | (I'm not a morning person.) |
[EMAIL PROTECTED] +--------------------------------------+
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
