[Python-checkins] r42954 - in python/trunk: Doc/lib/libunicodedata.tex Include/ucnhash.h Lib/encodings/idna.py Lib/stringprep.py Modules/unicodedata.c

Fri Mar 17 22:01:59 CET 2006

Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>>> This I don't understand: what new features could these
>>> be? All features of the Unicode database range back to
>>> the earliest versions, including data which we currently
>>> don't expose.
>>>> I meant new features as in: new fields in the database or
>> new values for categories.
>> I very much doubt that the Unicode consortium adds new
> fields in the database or new values for categories. If
> they ever do, we can worry about it then.
>> If you want to worry now: Adding a new category is completely backwards
> compatible. The category value just won't appear in the old version of
> the database, which doesn't cause any problems whatsoever.
>> For new fields in the database, we should assume that
> in older versions, the assigned characters have the same
> values of the properties as in the most recent version,
> unless the Unicode consortium specifies otherwise.
>>> If we expose new features that are only available in 4.1
>> and not in 3.2, then you have a compatibility problem
>> since the 3.2 version won't supply the needed data.
>> So you use the 4.1 data instead, and apply them to
> all characters that were assigned in 3.2.
>> However, there *are* no features that are available in
> 4.1 and not in 3.2.

True. I'm challenging your design decision and the fact
that you decided this on your own without getting feedback
via the SF tracker first.
>> The reason stringprep is tied to Unicode 3.2 stems from the
>> need to provide explicit tables for the string pre-processing.
>>>> I don't see why the IETF should not update the RFC with a new
>> set of tables against the Unicode 4.1 (or a later) database
>> version.
>> That shows that you haven't been following the IDNA discussions.
> Some of the IDNA authors are very concerned about changes to
> the normalization, and will strongly oppose proposals to move
> to a new version of the database.

No, I haven't followed that discussion. Just applying common
sense.
Note that I'm not arguing against having multiple versions
of the database around. On the contrary: I want to make this
a user choice and as easy for them to decide as possible.
-- 
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Mar 17 2006)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::