Mihai Ibanescu firstname.lastname@example.org writes:
Anyway, UCS4 is something I don't think we can change now - and after reading Martin's post, it makes me feel it's the correct way to go. How can we fix the tcl/python interaction? If you have suggestions, please let me know (off-list would be fine too).
For 2.3, I have fixed it in the way that you can build _tkinter in both UCS-2 and UCS-4 against a UCS-2 Tcl, and you can build a UCS-4 Python against a UCS-4 Tcl.
What is missing is building a standard (i.e. UCS-2) Python against the Redhat (i.e. UCS-4) Tcl. There is now a note in README telling people to configure Python for UCS-4 on Redhat. It appears that all Redhat 9 users running into that so far find that acceptable.
Still, it would slightly simplify the build procedure to support UCS-2 Python against UCS-4 Tcl. To do that, that case needs to be detected at compile time, and appropriate character-by-character conversions must be made. This is not on my TODO list, but I would accept patches that do that.
I have advised the Debian Python maintainer (Matthias Klose), that staying with UCS-2 for Python 2.2 is a good idea, as there are still problems left in 2.2. For 2.3, I have suggested that they build with UCS-4, especially as one Debian package requires that. So for compatibility across Linux distributions, I hope that distributors will configure Python 2.3 with UCS-4 on Linux.
P.S. What is IMO more urgently missing is "proper" support for that feature in Tcl, if it is meant to be a feature, in terms of documentation, configuration options, etc. Or, if Tcl maintainers decide this is *not* a desirable feature, it would help if they say so (but I think Jeff's comments indicate that this is unlikely).