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

Stephen J. Turnbull stephen at xemacs.org
Wed Apr 24 04:23:42 CEST 2013

R. David Murray writes:

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.

It's a problem because in that case it's hard for users to remember the directionality of the codec based only on a single name; the API needs to indicate what is being transformed to what else.

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.

I think that the intention of the proposal is reasonably understandable, and reasonable. I just don't think the API proposed is understandable, and therefore it's not reasonable.

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

I can't speak to the opinions of people who actually know about language design. For myself, I'm sympathetic to the proposal of a specific API limited to cases where the directionality is clear as a generality. I just don't think the "transform" proposal helps much, partly because the actual applications are few, and partly because "transform" is more ambiguous (to be unambiguous in English, you need both the direct object ("from media type") and the indirect object ("to media type") specified. It is quite possible to say "transform encoded text to raw text" or similar. At least for me, "encode transformed text to raw text" raises a WTFAssertion.

I know that I've experienced worlds of pain in the character coding sphere from Emacs APIs and UIs that don't indicate directionality clearly. This is very delicate; GNU Emacs had an ugly bug that regressed multiple times over more than a decade merely because they exposed the internal representation of text to Lisp. XEmacs has never experienced that bug (to be precise, the presence of that kind of bug resulted in an immediate assertion, so it was eliminated early in development). Surprisingly to me, the fact that XEmacs uses the internal representation of text to also represent "byte streams" (with bytes of variable width!) has never caused me confusion. It does cause others confusion, though, so although the XEmacs model of text is easier to work with than Emacs's, I tend to think Python 3's (which never confounds text with bytes) is better.

I suspect that delicacy extends to non-character transformations, so I am pretty demanding about proposals in this area. Specifically I insist on EIBTI and TOOWTDI.

More information about the Python-Dev mailing list