[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 11:19:59 CET 2006

Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>> Now we have two versions of the database in a single module
>> and if we want to upgrade to a new version in the future the
>> path taken by Martin now would have to be repeated, adding more
>> complexity.
>> What do you mean by "repeated"? That the next update should
> incorporate three versions? 

If someone comes up with an RFC pointing to version 4.1,
then yes, we'd have to keep it as well.
> Not necessarily: old versions can
> certainly be dropped if there is no need to keep them. We did
> not make a promise to provide access to all versions of the
> database that the Unicode consortium ever had released.

True.
>> Deprecation of an old version would not be user friendly,
>> since you can't warn on import, only on use of the lookup
>> object.
>> If you think a new module should be added in addition: that
> could certainly be done.

Sounds like a plan :-)
>> Adding support for new features in the Unicode database
>> would also be unnecessarily complicated, since the old
>> versions won't provide the needed input data.
>> 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.
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.
We'd either have to make up some defaults or raise an
error for these.
>> Currently, the only reason to keep 3.2 support around seems to
>> be the IDNA encoding (RFC 3490) which relies on stringprep
>> (RFC 3454) which is only defined for Unicode 3.2.0. It is however
>> likely that the stringprep RFC will get updated to later versions:
>>>> "This document is for Unicode version 3.2, and should not be considered
>> to automatically apply to later Unicode versions. The IETF, through an
>> explicit standards action, may update this document as appropriate to
>> handle later Unicode versions."
>> That doesn't say an update is likely. Indeed, it is not likely.
> This says the update is possible.

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.
-- 
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 ! ::::