Mailman 3 Extending locale.py - Python-Dev - python.org

newer
unicode regex quickie: should a...

Extending locale.py

older
SRE snapshot broken

M.-A. Lemburg

26 May 2000 26 May '00

8:19 p.m.

To make moving into the direction of making the string encoding depend on the locale settings a little easier, I've started to hack away at an extension of the locale.py module. The module provides enough information to be able to set the string encoding in site.py at startup. Additional code for _localemodule.c would be nice for platforms which use other APIs to get at the active code page, e.g. on Windows and Macs. Please try it on your platform and tell me what you think of the APIs. Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

Attachments:

localex.py (text/python — 25.5 KB)

Reply

Sign in to reply online Use email software

Show replies by date

M.-A. Lemburg

30 May 30 May

5:06 p.m.

Here is my second version of the module. It is somewhat more flexible and also smaller in size. BTW, I haven't found any mention of what language and encoding the locale 'C' assumes or defines. Currently, the module reports these as None, meaning undefined. Are language and encoding defined for 'C' ? (Sorry for posting the whole module -- starship seems to be down again...) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

Reply

Sign in to reply online Use email software

Fredrik Lundh

8:44 p.m.

M.-A. Lemburg wrote:

BTW, I haven't found any mention of what language and encoding the locale 'C' assumes or defines. Currently, the module reports these as None, meaning undefined. Are language and encoding defined for 'C' ?

IIRC, the C locale (and the POSIX character set) is defined in terms of a "portable character set". This set contains all ASCII characters, but doesn't specify what code points to use. But I think it's safe to assume 7-bit US ASCII. (Is anyone anywhere using Python on a non-ASCII platform? does it even build and run on such a beast?) </F> <project name="sre" complete="97.1%" />

Reply

Sign in to reply online Use email software

Andrew M. Kuchling

8:46 p.m.

On Tue, May 30, 2000 at 05:14:00PM +0200, Fredrik Lundh wrote:

But I think it's safe to assume 7-bit US ASCII. (Is anyone anywhere using Python on a non-ASCII platform? does it even build and run on such a beast?)

The OS/390 port of 1.4? (http://www.s390.ibm.com/products/oe/python.html) But it doesn't look like they ported the regex module at all. -- A.M. Kuchling http://starship.python.net/crew/amk/ Better get going; your parents still think me imaginary, and I'd hate to shatter an illusion like that before dinner. -- The monster, in STANLEY AND HIS MONSTER #1

Reply

Sign in to reply online Use email software

M.-A. Lemburg

11:24 p.m.

Fredrik Lundh wrote:

M.-A. Lemburg wrote:

...
BTW, I haven't found any mention of what language and encoding the locale 'C' assumes or defines. Currently, the module reports these as None, meaning undefined. Are language and encoding defined for 'C' ?

IIRC, the C locale (and the POSIX character set) is defined in terms of a "portable character set". This set contains all ASCII characters, but doesn't specify what code points to use.

But I think it's safe to assume 7-bit US ASCII. (Is anyone anywhere using Python on a non-ASCII platform? does it even build and run on such a beast?)

Hmm, that would mean having an encoding, but no language definition available -- setlocale() doesn't work without language code... I guess its better to leave things undefined in that case. Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

Reply

Sign in to reply online Use email software

8725

Age (days ago)

8729

Last active (days ago)

Download

4 comments

3 participants

tags

participants (3)

Andrew M. Kuchling
Fredrik Lundh
M.-A. Lemburg