[Request] Python with Unicode4 support
 

Dear Slackware developers,

as I ran into an issue today while using external libraries via python (CPLEX in this case), I'd like to ask what the stance on Unicode is.

By default, python is built with support for 16bit Unicode only, i.e. --enable-unicode=ucs2.
But many distributions nowadays have switched to compiling with --enable-unicode=ucs4, which prompted third-party developers to ship their binaries/libraries accordingly, making them impossible to use in Slackware without recompiling python itself and all its dependencies.

The reason I can see against adding configure parameters is the purity and cleanliness of the slackware-shipped binaries, but it doesn't have any other disadvantages I know of.

I've never figured out why anyone would want to use UTF-16, let alone UCS-2.

Are there any examples other than CPLEX?

As, granted, the number of applications relying on this isn't very high, I mostly found references to openssl which is e.g. used in the software "OpsCenter" by Datastax. (googling for PyUnicodeUCS4_Decode and PyUnicodeUCS2_Decode).

looking at this two links

http://community.activestate.com/node/9371
http://stackoverflow.com/questions/1...-unicode-error

I'm thinking if it's there any serious reason to switch to ucs4 from the default ucs2, as the two modes are incompatible, just for solving this two special cases you cite: not that it matters much (I think), but for personal curiosity which are the distributions that are using ucs4?
maybe it's IBM that it's just releasing the python components with this default to conform to a specific distribution to certify its product on a specific platform...

glibc uses a 32bit wchar. I don't know whether that has any bearing on python's internal unicode handling but it might explain why some of the other distros have opted for the ucs4 option.

Which distros are using ucs4? For the sake of compatibility it's probably best to run with the crowd and do whatever Redhat and debian are doing (assuming they're using the same setting of course).

I gave it a try here and so far it's required me to recompile sip, PyQt and a bunch of other non-standard Slack packages like numpy, scipy etc.

http://mail.python.org/pipermail/pyt...er/091933.html
Old post, but Debian and Fedora have switched to UCS4 years ago, don't know the current state of Archlinux though.
Edit: I didn't mention things like numpy and scipy because most users compile them manually anyway, it's more an issue with commercial libraries.

btw: python 3.3 dropped the compilation flag; see http://www.python.org/dev/peps/pep-0393/