[Python-Dev] Python's Unicode width default (New Py_UNICODE doc)

[M.-A. Lemburg]

Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
> 
>>Martin, please reconsider... the choice is between:
> 
> 
> The point is that this all was discussed, and decided the
> other way 'round. There is no point in going back and forth
> between the two choices:
> 
> http://mail.python.org/pipermail/python-dev/2003-June/036461.html

So you call two emails to the python-dev list a discussion ?

AFAICT, only Barry mildly suggested to have an automatic
--enable-unicode=ucs4 switch and then Jeff Epler provided
the patch including the warning that the patch wasn't tested
and that it does not attempt to make a more educated
guess as to where to find tcl.h (unlike setup.py does
in order to build _tkinter.c).

> If we remove the code, people will *again* report that
> _tkinter stops building on Redhat (see #719880). I
> see no value in breaking what works now.

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.

>>a) We have a cross-platform default Unicode width
>>   setting of UCS2.
> 
> 
> It is hardly the default anymore cross-platform. Many
> installations on Linux are built as UCS-4 now - no
> matter what configure does.

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).

>>b) The default Unicode width is undefined and the only
>>   thing we can tell the user is:
>>
>>   Run the configure script and then try the interpreter
>>   to check whether you've got a UCS2 or UCS4 build.
> 
> 
> It's not at all undefined. There is a precise, deterministic,
> repeatable algorithm that determines the default, and
> if people want to know, we can tell them.

The outcome of the configure tests is bound to be
highly random across installations since it depends
whether TCL was installed on the system and how it
was configured. Furthermore, if a user wants to build
against a different TCL version, configure won't detect
this change, since it's setup.py that does the _tkinter.c
compilation.

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.

I want to restore this fact which was true before
Jeff's patch was applied.

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.

>>I want to change the --enable-unicode switch back to
>>always use UCS2 as default and add a new option value
>>"tcl" which then triggers the behavior you've added to
>>support _tkinter, ie.
>>
>>    --enable-unicode=tcl
>>
>>bases the decision to use UCS2 or UCS4 on the installed
>>TCL interpreter (if there is one).
> 
> Please don't - unless you also go back and re-open the
> bug reports, change the documentation, tell the Linux
> packagers that settings have changed, and so on.
> 
> Why deliberately break what currently works?

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.

BTW, SuSE builds TCL using UCS2 which seems to be
the correct choice given this comment in tcl.h:
"""
 * At this time UCS-2 mode is the default and recommended mode.
 * UCS-4 is experimental and not recommended.  It works for the core,
 * but most extensions expect UCS-2.
"""
and _tkinter.c built for a UCS4 Python does work with
a UCS2 TCL.

About the documentation: this still refers to the UCS2
default build and will need to be updated to also
mention UCS4 anyway.

About the bug reports: feel free to assign them to me.
We can have a canned response if necessary, but I
doubt that it will be necessary.

Explicit is better than implicit :-)

-- 
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 ! ::::