Mit fremden Locale umgehen - datetime

[anogayales]

Hallo allerseits,

ich bekomme eine Liste von Daten (Singular: Datum) in der Form:

Code: Alles auswählen

12 October 2007

Das ganze ist also englisch. Falls man also Python mit den englischen bzw. amerikanischen Locale laufen lässt, könnte man das ganze anhand folgendem Code in eine Datetime objekt umwandeln:

Code: Alles auswählen

datetime.datetime.strptime(datestring, "%d %B %Y")

Das Problem ist, dass ich nicht so einfach die Locale wechseln kann. Natürlich geht das über

Code: Alles auswählen

locale.setlocale(locale.LC_ALL, 'en_US')

Aber manche Systeme haben eben diese Locale nicht nativ zur Verfügung, Beispiel: Windows 7 DEU.

Wie kann ich nun das Datum, ohne irgendwelche Spielereien mit einer Monats-Lookuptable, in eine Datetime objekt umwandeln?

Grüße,
anogayales

[b.esser-wisser]

Ein kurzer Test (unter Windows XP) zeigt, dass "locale.setlocale(locale.LC_ALL, 'english')" funktioniert - die Variante mit zwei bzw. vier Buchstaben funktioniert hier gar nicht.

[anogayales]

Aber wird es auch auf anderen Systemen so funktionieren?

Und außerdem: http://docs.python.org/library/locale.html

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.

Wie löse ich nun das Problem?

Grüße,
anogayales

[b.esser-wisser]

Wie löse ich nun das Problem?

Wohl genau so, wie im nächsten Absatz beschrieben:

If, when coding a module for general use, you need a locale independent version of an operation that is affected by the locale (such as 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.

... also von Hand (str.split, dict, und/oder regex).
Ein festes Datumsformat zu parsen ist ja nicht soo schwer.

hth, Jörg

[mkesper]

If, when coding a module for general use, you need a locale independent version of an operation that is affected by the locale (such as 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.

Ist imho ein Denkfehler der Library-Guys. Die Locale auf meinem System stimmt ja keineswegs zwangsläufig mit den zu verarbeitenden Daten überein. Und ansonsten gilt ja in Python der Grundsatz: Wenn es eine Lib dafür gibt, programmiere es nicht selbst!

[DasIch]

Und ansonsten gilt ja in Python der Grundsatz: Wenn es eine Lib dafür gibt, programmiere es nicht selbst!

Der Grundsatz gilt bestimmt nicht. Mir fallen da z.B. pyparsing, pymeta und ply ein die alle letztendlich dasselbe tun aber aus dem ein oder anderen Grund alle nicht zugebrauchen sind so dass ich meine eigene Lösung programmiere. Ich glaube sogar dass die meisten Projekte nicht deswegen angefangen werden weil irgendjemand eine innovative Idee hat sondern einfach weil die existierenden Lösungen für seinen Zweck oder generell einfach nicht zu gebrauchen sind.

Im konkreten Fall gibt es allerdings eine sinnvolle Lösung und die heisst zu vergessen das locale und gettext aus der stdlib existiert und Babel zu nutzen.

Wenn man locale.setlocale aufrufen muss geht die ganze Anwendung schon den Bach runter.

[BlackJack]

@DasIch: Natürlich gilt der Grundsatz. Du hast auch kein Argument dagegen gebracht. Du hast ja letztendlich gesagt dass es für Dein Problem keine geeignete Bibliothek gab und Du es deswegen selbst gelöst hast.