On Wed, May 14, 2008 at 5:16 PM, Greg Ewing <[EMAIL PROTECTED]> wrote: > Wasn't there a big discussion once before about whether > encode/decode should be usable for things other than > unicode<->non-unicode transformations? I thought the > conclusion reached back then was that they shouldn't.
That was before the idea was brought up to have separate APIs for the X<->X transforms. The reason to drop those was making the type signatures of .encode() and .decode() predictable, which is much more of a concern in 3.0 than it is in 2.x where it's basically string in, string out and whether that's unicode of 8-bit is a minor detail (in some cases at least). > Is there some reason the transformations being talked > about can't just be provided as functions that operate > on strings or bytes? Several people have explained that having these available as transformations and being able to register new transformations is very convenient; there is plenty of existing use in 2.x of this feature, so we're not inventing something new. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
