[I18n-sig] Strawman Proposal: Binary Strings
Paul Prescod
paulp@ActiveState.com
Thu, 08 Feb 2001 12:24:49 -0800
Toby Dickenson wrote:
>
> ...
>
> You say that precise coercion rules are a personal preference, but
> adding a coercion function just helps this ambiguity to persist.
>
> What if string.encode() returned a binary string.... would we need a
> 'binary()' builtin at all?
I guess not. But the encode method might already be in use. If we
combine your restrictive coercion suggestion with this suggestion we
might break some (admittedly newish) code. How about
"str.binencode(encoding)".
Also, it isn't entirely unbelievable that someone might want to encode
from a string to a string. e.g. base64 (do we call that an encoding??)
So having an binencode() seperate from encode() might be a good idea.
Alternate names are "binary", "asbinary", "tobinary", "getbinary" and
any underscore-separated variant.
> ...
> I agree any explicit coecion should follow the same rules as Unicode.
> Im not sure we agree on whether that coercion happens automatically
> and implicitly, as it does with Unicode strings; I feel fairly
> strongly that it shouldnt. (Ill justify that tomorrow if we do
> disagree).
If we were inventing something from whole cloth I would agree with you.
But I want people to quickly port their string-using applications over
to binary-strings and if we require a bunch more explicit conversions
then they will move more slowly.
Nevertheless, I'm not willing to fight about the issue. There are two
votes against coercion already and if the response is similarly
anti-coercion then I'll agree.
> An extra difference:
>
> d) The str() is the same as the repr().
That sounds okay with me...
Paul Prescod