> I like the idea in general, but worry that some conflicts may not be > resolvable. For instance, I don't know what goal drives system > packagers to specify UCS4 over the default UCS2
That is easy to say: feature support. You can't really call it "Unicode" if you can't index it by code point. Some parts of the API (e.g. the Unicode database) are incomplete in UCS-2 mode. A minor objective is C library compliance: wchar_t has also four bytes per character. > but I won't ever be > happy using a Python built that way for long-running, memory-intensive > applications, where I have measured the overhead of UCS4 and found it > unacceptable (e.g., a server app whose steady-state process size is > 800Mb under UCS4, compared to 600Mb under UCS2). I don't think this is really in the field of issues that Jim was talking about. In any case, if you have long-running memory-intensive applications, recompiling Python might be just the right thing to do. In the same direction, I wish people would understand that 64-bit Python builds just waste memory, and that they were better off with 32-bit implementations. >From the developer point of view, I'd wonder whether there is potential for some even more dramatic savings than 25%. Regards, Martin _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
