[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 19:31:57 CET 2006

M.-A. Lemburg wrote:
>>Well, "the problem" to be solved was not merely to provide two versions
>>of the database, but also in a space-efficient way. All this effort
>>in trying to squeeze the size of the data would be wasted when it
>>then gets double just because two versions of the database must
>>be provided.
>>> Since the big tables of the database are static C data,
> only the portions needed would ever get swapped into
> memory, so this argument is rather weak.

It's on-disk space that I worry about, not in-memory space.
What is your worry?
> Also, most users won't ever use the IDNA codec, so they'd
> benefit from not having the extra complexity around.

But they don't suffer from it, either. It just doesn't affect them.
> With the old version available in a separate module, users who
> still need the old version could continue to compile it for
> themselves.

That's true. However, this is no advantage: in the current
implementation, they don't have to do anything - the old
version is always available.
> If you change makeunicodedata.py, then there's no way back
> for these users.

Sure. They could fetch the old version from some old Python
distribution, rename the entry point, and compile the module
under a different name.
> Given that the stringprep RFC has started out by pointing
> to a specific Unicode version, it is likely that these
> strong binding to specific versions are going to happen
> again in the future.

"the future" meaning 2015, right?
> This makes it nearly impossible to remove the old database
> version support, since there's always be some users that
> will have to rely on the availability of the old database
> versions.

Well, it is possible to remove support for old features -
we are doing that all the time.
> As you've pointed out, the size is really irrelevant.
>> What about access speed ?

No change there, either.
Regards,
Martin