Mit fremden Locale umgehen - datetime

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Antworten
anogayales
User
Beiträge: 456
Registriert: Mittwoch 15. April 2009, 14:11

Donnerstag 8. Juli 2010, 21:41

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
Benutzeravatar
b.esser-wisser
User
Beiträge: 272
Registriert: Freitag 20. Februar 2009, 14:21
Wohnort: Bundeshauptstadt B.

Freitag 9. Juli 2010, 09:03

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
User
Beiträge: 456
Registriert: Mittwoch 15. April 2009, 14:11

Freitag 9. Juli 2010, 11:03

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
Benutzeravatar
b.esser-wisser
User
Beiträge: 272
Registriert: Freitag 20. Februar 2009, 14:21
Wohnort: Bundeshauptstadt B.

Freitag 9. Juli 2010, 11:55

anogayales hat geschrieben:Wie löse ich nun das Problem?
Wohl genau so, wie im nächsten Absatz beschrieben:
Python 2.x Doku hat geschrieben: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
Wir haben schon 10% vom 21. Jahrhundert hinter uns!
Benutzeravatar
mkesper
User
Beiträge: 919
Registriert: Montag 20. November 2006, 15:48
Wohnort: formerly known as mkallas
Kontaktdaten:

Freitag 9. Juli 2010, 13:16

Python 2.x Doku hat geschrieben: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
User
Beiträge: 2532
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

Freitag 9. Juli 2010, 13:39

mkesper hat geschrieben: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

Freitag 9. Juli 2010, 13:53

@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.
Antworten