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

Tue Mar 14 21:58:03 CET 2006

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? 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.
> 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.
> 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.
> 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.
Regards,
Martin