Python incompatibility

[Mike Hearn]

Hi,

The copy of Python 2.4 shipped with Fedora Core 4 is configured to use
4-byte unicode instead of 2-byte, which is the upstream default. Modifying
this changes the exported API of libpython and breaks compatibility with
other distributions which is, needless to say, a Very Bad Thing.

Does anybody know why this is done? Is there any chance of fixing this
with a future version of the Python packages?

thanks -mike

[Gregory Maxwell]

On 11/20/05, Mike Hearn <mike(a)plan99.net&gt; wrote:
>  The copy of Python 2.4 shipped with Fedora Core 4 is configured to
> use
>  4-byte unicode instead of 2-byte, which is the upstream default. Modifying
>  this changes the exported API of libpython and breaks compatibility with
>  other distributions which is, needless to say, a Very Bad Thing.
>
>  Does anybody know why this is done? Is there any chance of fixing this
>  with a future version of the Python packages? 
It's a binary incompatible change, not a source incompatible one, right?
There is no promise that you can run binaries made on another distro.

The use of 4byte UTF has come in handy for me a number of times,
without it you can't handle characters outside of the BMP, this really
should be the default upstream.

[Mike Hearn]

>  The use of 4byte UTF has come in handy for me a number of times,
>  without it you can't handle characters outside of the BMP, this really
>  should be the default upstream. 
Possibly this should be taken upstream instead of simply changed in Fedora
then, so the change is synchronised?

[Jeff Pitman]

On 11/20/05, Mike Hearn <mike(a)plan99.net&gt; wrote:
>  > The use of 4byte UTF has come in handy for me a number of times,
>  > without it you can't handle characters outside of the BMP, this really
>  > should be the default upstream.
>
>  Possibly this should be taken upstream instead of simply changed in Fedora
>  then, so the change is synchronised?
>  
I'm not sure what change you're looking for, but, going forward it's ucs4.
Some cursory searches about the issue show that Tcl/Tk needs it and xml
processing stuff recommend it. If you want to provide binary extensions,
notice that the mx folks provide an RPM for the UCS2 build and one for the
UCS4 build. Not sure if Mihai will see this thread, but, I do remember
discussing this in length with him at one point. IIRC, it's not fixed
upstream because of some serious performance hits dealing with it and the
BDFL, et al. didn't want to go there. More searches required to dig this
up...

--
-jeff

[Mike Hearn]

>  If you want to provide binary extensions,
>  notice that the mx folks provide an RPM for the UCS2 build and one for the
>  UCS4 build. 
Ouch ... how are users expected to know which they have?

[Jeff Pitman]

On 11/21/05, Mike Hearn <mike(a)plan99.net&gt; wrote:
>  > If you want to provide binary extensions,
>  > notice that the mx folks provide an RPM for the UCS2 build and one for
>  the
>  > UCS4 build.
>
>  Ouch ... how are users expected to know which they have?
>  
If you are creating an uber-RPM that's supposed to work on 50 different
platforms, then the burden is on you to provide two libs that are compiled
against a UCS2 and a UCS4 build of Python. Then you use a highly unmotivated
trick to determine which Python was configured with during the
installation/configure stage (post package install).

--
-jeff