>> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
