RetroSearch Browse

Sat Aug 11 01:01:19 CEST 2007 · https://mail.python.org/pipermail/python-dev/2007-August/074140.html

>> Sure. But (again): you don't need to have the mappings at all for
>> what you want to achieve. So there is no point in downloading them
> 
> Sigh.  No, I don't.  But, if I want to be able to merge anything
> back into the main Python source, it is a VERY good idea to use the
> existing mechanisms and not invent new ones.

I think you still don't understand. Why I keep calling "mappings"
is *unrelated* to unicodedata. unicodedata is a different database, and
not related at all to the makefile. It never was.

> As I pointed out, there is already a problem where upgrading the data
> needs a complete rebuild to get all of the Unicode data back in step;
> 'make all' in itself does not work.  That is precisely the sort of
> problem that is caused by having duplicate update mechanisms.

Right. Downloading the necessary files is a completely manual process,
not supported at all by "make all", which is designed to do something
entirely different.

> Now, IF I can work out how the _sre.c engine works enough to put
> atomic/possessive quantifiers in, this problem will return.  My
> question would be how best to make a suitable proposal that, inter
> alia, includes changes that can't be made by the normal building
> mechanisms.
> 
> And I still don't have a clue about that one.

You lost me somewhere. What are "changes that can't be made by the
normal building process", and what is "this problem" that will
return?

Regards,
Martin

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2007-August/074140.html below:

[Python-Dev] Unicode database