Martin v. Löwis wrote: > M.-A. Lemburg wrote: > >>I'm not breaking anything, I'm just correcting the >>way things have to be configured in an effort to >>bring back the cross-platforma configure default. > > Your proposed change will break the build of Python > on Redhat/Fedora systems.
You know that this is not true. Python will happily continue to compile on these systems. >>I'm talking about the *configure* default, not the >>default installation you find on any particular >>platform (this remains a platform decision to be made >>by the packagers). > > > Why is it good to have such a default? Why is that > so good that its better than having Tkinter work > by default? It is important to be able to rely on a default that is used when no special options are given. The decision to use UCS2 or UCS4 is much too important to be left to a configure script. >>The main point is that we can no longer tell users: >>if you run configure without any further options, >>you will get a UCS2 build of Python. > > > It's not a matter of telling the users "no longer". > "We" currently don't tell that in any documentation; > if you had been telling that users, you were wrong. > > ./configure --help says that the default for > --enable-unicode is "yes". Let's see: http://www.python.org/peps/pep-0100.html http://www.python.org/peps/pep-0261.html http://www.python.org/doc/2.2.3/whatsnew/node8.html Apart from the mention in the What's New document for Python 2.2 and a FAQ entry, the documentation doesn't mention UCS4 at all. However, you're right: the configure script should print "(default if ucs2)". >>I want to restore this fact which was true before >>Jeff's patch was applied. > > > I understand that you want that. I'm opposed. Noted. >>Telling users to look at the configure script printout >>to determine whether they have just built a UCS2 >>or UCS4 is just not right given its implications. > > Right. We should tell them what the procedure is that > is used. No, we should make it an explicit decision by the user running the configure script. BTW, a UCS4 TCL is just as non-standard as a UCS4 Python build. Non-standard build options should never be selected by a configure script all by itself. >>It will continue to work - the only change, if any, >>is to add --enable-unicode=tcl or --enable-unicode=ucs4 >>(if you know that TCL uses UCS4) to your configure >>setup. The --enable-unicode=ucs4 configure setting >>is part of RedHat and SuSE already, so there won't >>be any changes necessary. > > Yes, but users of these systems need to adjust. Not really: they won't even notice the change in the configure script if they use the system provided Python versions. Or am I missing something ? Regardless of all this discussion, I think we should try to get _tkinter.c to work with a UCS4 TCL version as well. The conversion from UCS4 (Python) to UCS2 (TCL) is already integrated, so adding support for the other way around should be rather straight forward. Any takers ? Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 13 2005) >>> 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 ! :::: _______________________________________________ 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
