[Python-checkins] r42954 - in python/trunk: Doc/lib/libunicodedata.texModules/unicodedata.c

[M.-A. Lemburg]

Martin v. Löwis wrote:
> 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?

Code complexity.

On-disk space is not an argument anymore nowadays. Even
less so since we're only talking 100kBs and not even MBs.

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

The users don't. The developers do. I'm one of them, remember ?

>> 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?

Who knows. It happened in 2003. Could happen again in 2006.

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

Right, but there's usually a way to maintain old code
outside Python, e.g. keep deprecated modules around in
your own lib or continue to use regex because some old
application relies on it.

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