[Zope3-dev] Re: Getting rid of ASCII schema field
Tres Seaver
tseaver at zope.com
Mon Jan 19 10:17:18 EST 2004
Philipp von Weitershausen wrote:
> Tres,
>
>>> one last ward in the schema package remains: the ASCII field. Maybe
>>> there's a deeper reason for its existence, I certainly can't see it.
>>> 8-byte strings should be stored with the Bytes field. Morover, ASCII
>>> is totally equivalent to the Bytes field, so it doesn't even make a
>>> difference. The few times where it's used in the Zope 3 source I see
>>> no reason for not using Bytes.
>>>
>>> Unless someone has the mercy to enlighten me what ASCII could
>>> possibly be useful for, I will remove it next week :).
>>
>>
>> -1. Using an ASCII field documents an intent to store only
>> "7-bit-clean" values in the string; no characters > DEL (chr(127))
>> should be allowed. A number of applications exist which require such
>> a constraint (think RFC 822 headers, for instance).
>
>
> Thanks for clearing that up. I hadn't thought of *7bit* ASCII... quite
> an anachronism that is!
Nope; even in the Brave New World of Unicode, only the 7-bit chars are
universally unambiguous; the high-order-bit-set chars can't be
interpreted without an encoding, either implied or explicit. "8-bit
ASCII" is a nonsense term, actually; the standard itself doesn't
contemplate anything about values > DEL.
>> If, in fact, the ASCII field does not *enforce* that constraint, then
>> we should remedy that.
>
>
> Yes. I won't probably be the last one stumbling over this... I will fix
> the docstring and enforce correct validation then.
Great!
Tres.
--
===============================================================
Tres Seaver tseaver at zope.com
Zope Corporation "Zope Dealers" http://www.zope.com
More information about the Zope3-dev
mailing list