On Wed, 24 Apr 2013 01:49:39 +0900, "Stephen J. Turnbull" <step...@xemacs.org>
wrote:
> R. David Murray writes:
> > On Tue, 23 Apr 2013 22:29:33 +0900, "Stephen J. Turnbull"
> <step...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
