"Greg Ewing" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Efficiency is an implementation concern.
It is also a user concern, especially if inefficiency overruns memory limits. > In Py3k, strings > which contain only ascii or latin-1 might be stored as > 1 byte per character, in which case this would not be an > issue. If 'might' becomes 'will', I and I suspect others will be happier with the change. And I would be happy if the choice of physical storage was pretty much handled behind the scenes, as with the direction int/long unification is going. > Which is why I think that only *unicode* codings should be > available through the .encode and .decode interface. Or > alternatively there should be something more explicit like > .unicode_encode and .unicode_decode that is thus restricted. I prefer the shorter names and using recode, for instance, for bytes to bytes. Terry Jan Reedy _______________________________________________ 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
