python with UCS4 as default, Was: Re: python.include setting?

[Ned Deily]

In article <20130409201118.GC19415 at towel.neverpanic.de>,
 Clemens Lang <cal at macports.org> wrote:
> On Tue, Apr 09, 2013 at 12:12:49PM -0700, Ned Deily wrote:
> > The +ucs4 variant went away in Python 3.3.
> 
> That's good news to me :) One variability option less to worry about.
> 
> I've always wondered why MacPorts still offers the choice of using ucs2,
> where the rest of the (distribution) world seems to have agreed on ucs4
> (e.g. debian: [1]). Maybe we should finally make the switch and drop the
> variant?
> 
> [1] http://bazaar.launchpad.net/~doko/python/pkg2.7-debian/view/head:/rules

Well, not *all* of the world uses the ucs4 option.  In particular, the 
python.org binary installers for OS X and the Apple-supplied system 
Pythons use the default ucs2 for both Python 2 and Python 3, up to 3.3.  
I believe the python.org Windows installers do, too.  One reason, I 
believe, was the historical lack of wide-Unicode support in dependent 
components, like Tk and ncurses, and possibly in OS X APIs.  On current 
OS releases and in a MacPorts environment which supplies its own copies 
of the problematic system-supplied libs, like ncurses,  this shouldn't 
be much of an issue.  However, changing the default midstream in a major 
release cycle means the ABI for user-supplied C extension modules also 
changes and would require users to rebuild (and possibly modify) all of 
their own non-pure Python packages.  Starting with 3.3, Python 
automatically chooses the best of several possible internal 
representations for strings; from a user and ABI perspective, strings 
are now always wide (ucs-4).  So the problem will go away for Python 3 
users with the current and future releases.  It's probably too 
disruptive to change Python 2 now as activity on it slowly winds down.

FYI, Python 2.7.4 and 3.2.4 were also released this weekend along with 
Python 3.3.1 (the python33 port has already been updated).  3.2.4 is 
intended to be the last bugfix release for 3.2.x; only security fixes as 
necessary until 2016-02.  3.1.x no longer receives any bugfixes and will 
be retired from security-fix-only mode as of 2014-06.  2.6.x will be 
retired from security-fix-only mode as of 2013-10.  All earlier releases 
of Python 2 (i.e. 2.4.x and 2.5.x) and 3.0.x are already fully retired - 
no fixes of any kind.  So, at the moment the only branches actively 
receiving bugfixes are Python 3.3.x and 2.7.x.  No official date has 
been set yet to stop supplying bugfixes for 2.7.x but it is likely to be 
somewhere in the next two to four years.

-- 
 Ned Deily,
 nad at acm.org