Copyright (C) 2000-2012 |
GNU Info (python2.1-lib.info)BackgroundBackground, details, hints, tips and caveats -------------------------------------------- The C standard defines the locale as a program-wide property that may be relatively expensive to change. On top of that, some implementation are broken in such a way that frequent locale changes may cause core dumps. This makes the locale somewhat painful to use correctly. Initially, when a program is started, the locale is the `C' locale, no matter what the user's preferred locale is. The program must explicitly say that it wants the user's preferred locale settings by calling `setlocale(LC_ALL, '')'. It is generally a bad idea to call `setlocale()' in some library routine, since as a side effect it affects the entire program. Saving and restoring it is almost as bad: it is expensive and affects other threads that happen to run before the settings have been restored. If, when coding a module for general use, you need a locale independent version of an operation that is affected by the locale (e.g. `string.lower()', or certain formats used with `time.strftime()')), you will have to find a way to do it without using the standard library routine. Even better is convincing yourself that using locale settings is okay. Only as a last resort should you document that your module is not compatible with non-`C' locale settings. The case conversion functions in the `string' module are affected by the locale settings. When a call to the `setlocale()' function changes the `LC_CTYPE' settings, the variables `string.lowercase', `string.uppercase' and `string.letters' are recalculated. Note that this code that uses these variable through ``from' ... `import' ...', e.g. `from string import letters', is not affected by subsequent `setlocale()' calls. The only way to perform numeric operations according to the locale is to use the special functions defined by this module: `atof()', `atoi()', `format()', `str()'. automatically generated by info2www version 1.2.2.9 |