RetroSearch Browse

Wed Feb 22 20:32:30 CET 2006 · https://mail.python.org/pipermail/python-dev/2006-February/061719.html

"Greg Ewing" <greg.ewing at canterbury.ac.nz> wrote in message 
news:43FC4C8B.6080300 at canterbury.ac.nz...
> 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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2006-February/061719.html below:

[Python-Dev] bytes.from_hex()