[Python-3000] Binary compatibility

"Martin v. Löwis" martin at v.loewis.de
Thu Aug 9 10:30:53 CEST 2007


>> I see why a guarantee would help, but I don't think it's necessary.
>> Just provide UCS-4 binaries only on Linux, and when somebody complains,
>> tell them to recompile Python, or to recompile your software themselves.
> 
> Won't recompiling Python break every other Python program on their system,
> though? (e.g. anything that itself uses a C Python library)

It depends. If they use their own Python installation, just tell them
to use the vendor-supplied one instead - it likely is UCS-4.

If the vendor-supplied one is UCS-2, talk to the vendor. For the user,
tell them to make a separate installation (e.g. in /usr/local/bin).
This won't interfere with the existing installation.

> Also, anything involving recompiling isn't exactly user friendly... we
> might give Linux a bad name!

Hmm. Some think that Linux has becoming worse when people stopped
compiling the kernel themselves.

>> The defaults in 2.5.x cannot be changed anymore. The defaults could
>> be changed for Linux in 2.6, but then the question is: why just for
>> Linux?
> 
> Are there different Windows python binaries around with different UCS-2/4
> settings?

No. The definition of Py_UNICODE on Windows is mandated by the operating
system, which has Unicode APIs that are two-bytes, and Python wants to
use them.

> BTW, none of this is urgent. We experimented with Python/C hybrids in the
> past. It didn't work, so we carried on using pure C programs for anything
> that needed any part in C. So it's not causing actual problems for users
> right now. It would just be nice to have it sorted out one day, so we
> could use Python more in the future.

I can understand the concern, but I believe it is fairly theoretical.
Most distributions do use UCS-4 these days, so the problem went away
by de-facto standardization, not by de-jure standardization.

Regards,
Martin



More information about the Python-3000 mailing list