[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