2008-09-26 4 views
2

Nous utilisons un produit middleware tiers qui nous permet d'écrire du code dans un interpréteur Python intégré et qui expose une API dans laquelle nous pouvons appeler. Certains de ces appels API nous permettent de charger différents types de fichiers, et le code de chargement est implémenté en C. Le chargement du fichier se fait dans un thread séparé, et rappelle en Python lorsque les données sont disponibles. Jusqu'ici, tout va bien et dandy.Utiliser locale.setlocale en Python embarqué sans casser l'analyse de fichier dans le thread C

Nous avons été i14ing (heh) notre produit, et une chose que nous aimerions faire est de formater la sortie numérique orientée utilisateur en fonction des paramètres régionaux de l'utilisateur. Donc, à partir de Python, nous le faisons:

import locale 
locale.setLocale(locale.LC_ALL, '') 

Maintenant, cela fonctionne (en ce que les numéros faisant face à l'utilisateur sont correctement mis leur section locale). Cependant, si les paramètres régionaux de l'utilisateur diffèrent des paramètres régionaux C par défaut, tous les fichiers chargés ultérieurement renverront des données incorrectes, probablement parce que toute conversion de chaîne à flottant a été affectée, jusqu'au métal. Nous ne pouvons pas contourner ce problème en implémentant le chargement de fichiers prenant en compte les paramètres régionaux. Notre solution de contournement actuelle consiste donc à définir uniquement les paramètres régionaux lors du formatage de la sortie pour l'utilisateur, puis à le rétablir ultérieurement. Autrement dit, quelque chose comme:

import locale 
currentLocale = locale.getLocale(locale.LC_ALL) 
locale.setLocale(locale.LC_ALL, '') 
displayNumbersToTheUser() 
locale.setlocale(locale.LC_ALL, currentLocale) 

Cela semble un peu maladroit, et je me demandais si cela est une approche commune de formatage de la sortie conscient de la localisation de l'utilisateur? Mon autre souci est que ce n'est évidemment pas thread-safe, donc nous aurons probablement encore des problèmes si n'importe quelle analyse de fichier se produit dans un thread séparé lorsque les paramètres régionaux sont modifiés.

Toute information sur les meilleures pratiques est appréciée - je n'ai pas beaucoup d'expérience avec ce genre de chose.

+0

Je ne suis pas sûr de comprendre quel est le problème. Comment exactement les paramètres régionaux de l'utilisateur affectent la capacité de vos applications à charger des fichiers? Comment convertis-tu la chaîne en float en C? – nosklo

+0

Désolé que je n'ai jamais vu votre commentaire; définir les paramètres régionaux avec LC_ALL affecte strtof() et ainsi de suite, de sorte que le nombre "10.0" peut être interprété comme "100", par exemple. – kranzky

Répondre

1

La définition des paramètres régionaux après le démarrage de plusieurs threads peut avoir des résultats inattendus. À moins que je ne puisse trouver une approche plus subtile, je partagerais probablement le chargement de fichiers et l'interface utilisateur en processus séparés, en communiquant via un canal ou un socket de fichier.

+0

Oui, et nous ne pouvons évidemment pas définir les paramètres régionaux avant que les threads ne commencent à fonctionner, car cela modifie la façon dont ils traitent les données qu'ils chargent à partir des fichiers. Il semble qu'il n'y ait pas de solution pour nous, à part écrire notre propre code pour afficher des nombres correctement formatés à l'utilisateur. Merci quand même! – kranzky

Questions connexes