On Wed, 24 Apr 2013 01:49:39 +0900, "Stephen J. Turnbull" <stephen@xemacs.org> wrote:
R. David Murray writes:
On Tue, 23 Apr 2013 22:29:33 +0900, "Stephen J. Turnbull" <stephen@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