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

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 :)

--David

More information about the Python-Dev mailing list