[Python-Dev] Why can't I encode/decode base64 without importing a module?

R. David Murray rdmurray at bitdance.com
Tue Apr 23 20:05:20 CEST 2013

On Wed, 24 Apr 2013 01:49:39 +0900, "Stephen J. Turnbull" <stephen at xemacs.org> wrote:
> R. David Murray writes:
>  > On Tue, 23 Apr 2013 22:29:33 +0900, "Stephen J. Turnbull" <stephen at xemacs.org> wrote:
>  > > R. David Murray writes:
>  > > 
>  > >  > You transform *into* the encoding, and untransform *out* of the
>  > >  > encoding.  Do you have an example where that would be ambiguous?
>  > > 
>  > > In the bytes-to-bytes case, any pair of character encodings (eg, UTF-8
>  > > and ISO-8859-15) would do.  Or how about in text, ReST to HTML?
>  > 
>  > If I write:
>  > 
>  >   bytestring.transform('ISO-8859-15')
>  > 
>  > that would indeed be ambiguous, but only because I haven't named the
>  > source encoding of the bytestring.  So the above is obviously
>  > nonsense, and the easiest "fix" is to have the things that are currently
>  > bytes-to-text or text-to-bytes character set transformations *only*
>  > work with encode/decode, and not transform/untransform.
> I think you're completely missing my point here.  The problem is that
> in the cases I mention, what is encoded data and what is decoded data
> can only be decided by asking the user.

I think I understood that.  I don't understand why that's a problem.
(But see below.)

>  > Given this, the possible valid transformations would be:
>  > 
>  >   bytestring.transform('base64')
>  >   bytesstring.untransform('base64')
>  >   string.untransform('base64')
> Which is an obnoxious API, since (1) you've now made it impossible to
> use "transform" for
>     bytestring.transform(from='utf-8', to='iso-8859-1')
>     bytestring.transform(from='ulaw', to='mp3')
>     textstring.transform(from='rest', to='html')
> without confusion, and (2) the whole world is going to wonder why you
> don't use .encode and .decode instead of .transform and .untransform.

I've been trying to explain what I thought the transform/untransform
proposal was: a minimalist extension of the encode/decode semantic
(under a different name) so that functionality that was lost from
Python2 encode/decode could be restored to Python3 in a reasonably
understandable way.  This would be a *limited* convenience function,
just as encode/decode are limited convenience functions with respect to
the full power of the codecs module.

I myself don't have any real investment in the proposal, or I would
have long since tried to push the tracker issue forward.

People (at least you and Nick, and maybe Guido) seem to be more interested
in a more general/powerful mechanism.  I'm fine with that :)


More information about the Python-Dev mailing list