ANN: Experimental Number Types (Integer, Rational, Floats)

[Carlos Ribeiro]

At 17:12 26/04/01 +0000, David LeBlanc wrote:
>Looking at this from a broader perspective, in light of the move towards
>Unicode, isn't internationalization (i18n) and localization (l8n - L18n)
>going to become a more pervasive issue? From radix specifiers ("." US,
>"," European) to date formats and beyond, global acceptance of Python is
>going to be somewhat dependent on idioms familiar to a particular group
>IMHO.

A similar issue is already happening with VB. In the brazilian edition of 
the Office suite, the library functions got their names translated. Note 
that I dont think that this is a good idea, but I see the reason behind 
Microsoft's choice. They expect that the users should be able to write 
macros for their Excel worksheets, and what is better than naming the 
functions in the native language of the user?

The same applies to importing/exporting data to/from applications. Date 
formats and comma/period issues cause lots of problems. Sometimes we get 
text files (log dumps from some equipment, for example) that are formatted 
using US localization. To import this files in Excel, you have to change 
the locale to US, import the file, and then change it back to Brazil.  (Of 
course, I solved my problem using a Python script to convert notations, but 
the example is still valid for the majority of users).

A complete solution for this problem is very far, far away. There are two 
pieces in it:

1) the internal data format needs to be locale-independent;
2) locale information needs to included in the file, either as:
    a) as a permanent attribute of the file, preserved in backups
       or downloads.
    b) in some place on every file header, including text files.


Carlos Ribeiro