[Python-Dev] Why can't I encode/decode base64 without importing a module?
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
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.<wink/>
> 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