Hi! Ich habe festgestellt das bei Python die Unix-Zeit bei etwa +2 100 000 000 Sekunden aufhört. Ist das "Konvention" oder nur eine Python-Beschränkung? Weil wen bei Unix nach +2 100 000 000 Sekunden "alles zu Ende ist", würde bei meiner PostgreSQL-DB in Integer-Typ reichen (+2 Mrd.) MfG Olaf _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Olaf 'ruebezahl' Radicke wrote:
Hi!
Ich habe festgestellt das bei Python die Unix-Zeit bei etwa +2 100 000 000 Sekunden aufhört. Ist das "Konvention" oder nur eine Python-Beschränkung?
Hab kein Bock das jetzt genau nachzulesen, wenn jemand in POSIX usw. fitter ist wird man mich schon berichtigen, wenn ich Blödsinn erzähle: Die Unix-Zeitfunktionen verwenden als Einheit time_t, das im Normalfall ein int ist, der im Normalfall 32 Bit lang ist (auf manchen Maschinen 64 Bit). Du hast wohl eine 32-Bit Maschine vor dir ;-)
Weil wen bei Unix nach +2 100 000 000 Sekunden "alles zu Ende ist", würde bei meiner PostgreSQL-DB in Integer-Typ reichen (+2 Mrd.)
Erhm. Was du willst, ist höchstwahrscheinlich der Typ TIMESTAMP. Es besteht keinerlei Notwendigkeit, bei PostgreSQL oder bei Python da selber was rumzupfiemeln. Dafür gibt's bei PostgreSQL die enstprechenden Datentypen und Zeitfunktionen und bei Python mxDateTime aus den mxExtensions [1]. Hier mal ein Beispiel aus einer interaktiven Session, was alles geht:
from pyPgSQL import PgSQL from mx.DateTime import * cx = PgSQL.connect() cu = cx.cursor() cu.execute("create table test(t1 timestamp, t2 timestamp)") t1 = now() t2 = t1 + oneWeek t1, t2 (<DateTime object for '2003-12-02 17:35:23.32' at 81bba50>, <DateTime object for '2003-12-09 17:35:23.32' at 818b150>) t2 - t1 <DateTimeDelta object for '7:00:00:00.00' at 81d50e0> cu.execute("insert into test(t1, t2) values (%s, %s)", (t1, t2)) cu.execute("select t1, t2 from test") print cu.fetchone() [<DateTime object for '2003-12-02 17:35:23.32' at 81e0be8>, <DateTime object for '2003-12-09 17:35:23.32' at 81e3070>] cu.execute("select t2 - t1 from test") print cu.fetchone() [<DateTimeDelta object for '7:00:00:00.00' at 81ee9e8>] cx.close()
-- Gerhard [1] Ab 2.3 gibt's auch das eingebaute datetime-Modul, aber a) funktioniert mein PostgreSQL-Adapter pyPgSQL damit (noch) nicht und b) fehlen dem builtin-Modul noch die ganzen Methoden zum Parsen von Datums-/Zeitstrings. _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Am Dienstag, 2. Dezember 2003 17:44 schrieb Gerhard Häring: [...]
Erhm. Was du willst, ist höchstwahrscheinlich der Typ TIMESTAMP. Es besteht keinerlei Notwendigkeit, bei PostgreSQL oder bei Python da selber was rumzupfiemeln. Dafür gibt's bei PostgreSQL die enstprechenden Datentypen und Zeitfunktionen und bei Python mxDateTime aus den mxExtensions [1]. [...]
...Sehr beeindruckend! Für meine Operationen ist Unix-Time sehr praktisch. Ich habe mir dazu eine eigene Klasse geschrieben, die das kapselt, so das ich wenn ich mal mit "Bort-Mitteln" weiterkomme sie auch weiter ausbauen kann. Z.B. mit deinen Vorschlägen. MfG Olaf _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Gerhard Häring <gh@ghaering.de> writes:
Die Unix-Zeitfunktionen verwenden als Einheit time_t, das im Normalfall ein int ist, der im Normalfall 32 Bit lang ist (auf manchen Maschinen 64 Bit). Du hast wohl eine 32-Bit Maschine vor dir ;-)
Es ist üblicherweise long, der im Normalfall 32 Bit lang ist und auf manchen Maschinen 64 bit. Ciao, Martin _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Martin v. Löwis wrote:
Es ist üblicherweise long, der im Normalfall 32 Bit lang ist und auf manchen Maschinen 64 bit.
Ich dachte, mal gehört zu haben, daß man bestrebt ist, eine 64 Bit Implementierung auch in der 32 Bit Welt einzuführen. Grüße Daniel -- nihil me cirumdat _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
"daniel.poelzleithner" <poelzi@poelzi.org> writes:
Es ist üblicherweise long, der im Normalfall 32 Bit lang ist und auf manchen Maschinen 64 bit.
Ich dachte, mal gehört zu haben, daß man bestrebt ist, eine 64 Bit Implementierung auch in der 32 Bit Welt einzuführen.
Das geht in aktuellen Systemen nicht wegen der Rückwärtskompatibilität. Andererseits sind bis 2038 vermutlich die meisten 32-bit-Systeme außer Betrieb und durch 64-bit-Systeme ersetzt, so daß sich das Problem von selbst erledigt. Ciao, Martin _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Martin v. Löwis wrote:
Das geht in aktuellen Systemen nicht wegen der Rückwärtskompatibilität. Andererseits sind bis 2038 vermutlich die meisten 32-bit-Systeme außer Betrieb und durch 64-bit-Systeme ersetzt, so daß sich das Problem von selbst erledigt.
Das glaube ich nicht, denn bei der Umstellung auf 64 Bit Dateigröße gings ja auch. Ansonsten führt man halt neue aufrüfe wie time64() oder ähnliches ein. "Aber stimmt schon, 8 und 16 Bit Computer gibt es ja heute auch nichtmehr" ;) Grüße Daniel -- nihil me cirumdat _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
On Tue, Dec 02, 2003 at 10:17:49PM +0100, Martin v. Löwis wrote:
Rückwärtskompatibilität. Andererseits sind bis 2038 vermutlich die meisten 32-bit-Systeme außer Betrieb und durch 64-bit-Systeme ersetzt, so daß sich das Problem von selbst erledigt.
Ähnliche Gedanken hatte man im letzten Jahrtausend schon einmal ... -- Jens Kubieziel http://www.kubieziel.de "Die Presse ist fuer mich Druckerschwaerze auf Papier." (Otto von Bismarck) _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Jens Kubieziel <python@kubieziel.de> writes:
Ähnliche Gedanken hatte man im letzten Jahrtausend schon einmal ...
Ja, aber diesmal klappt's :-) Wir werden sehen. Ciao, Martin _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Da wir hier mal wieder ein Unicodeproblem haben, möchte ich schamlos auf einen meiner unzähligen Ergüsse hinweisen: http://p-nand-q.com/python/unicode_faq.html und die Gelegenheit nutzen, nochmals gegen Windmühlen anzurennen. Vorneweg: Unicode ist die "richtigere" Art, in Programmen mit Text umzugehen. All die Unterscheidungen zwischen "ASCII", "Bytestrings" und "UNICODE" sind vollkommen berechtigt. Das ist alles ganz richtig, das gebe ich alles zu. Damit habe ich kein Problem, ok? Du hast vollkommen recht! Niemand wiederspricht dir! HALLELUJAH! Es geht vielleicht um etwas ganz anderes: immer wieder laufen Leute in Probleme, da in Python Fehler in der Unicode-Text-Behandlung sofort zu Exceptions (und damit in der Regel zu einem Programmstop) führen. Diese Fehler treten nach Murphy natürlich immer dann auf, wenn man sie gerade nicht brauchen kann, und zwar zu 95% nach dem Abnahmetest. Da sagt die "Wir-haben-richtig"-Fraktion: Siehst du, hast du Fehler, musst du ausbessern, ist besser so! Das alles mag schon sein, aber das ist die falsche Zielsetzung: es geht nicht darum, ein ästhetisches Ziel zu erreichen (das "fehlerfreie" Programm, ein Konzept mit höchstens einer Handvoll Instanzen - "tex" z.B) sondern ein praktisches Ziel (z.B. ein Gerät anzusteuern in meinem Fall). Und da gibt es ein so altes Konzept wie die Relevanzabschätzung: wie relevant ist das Problem, wenn in z.B. einem Logfile ein ü ein ? ist? Genau: komplett irrelevant. Extrembeispiel: Wenn du auf der Autobahn deinen Todestrieb auslebst, möchtest du auch nicht, daß der Bremscomputer plötzlich einen Stunt hinlegt, weil "eine schwere Ausnahmebedingung aufgetreten ist". Nein, du willst daß er abschätzt: was ist wichtiger, behandle ich einen schimmligen Umlaut, oder erzeuge ich eine schimmlige Leiche? Deshalb ist es mein Vorschlag, einen Parameter einzuführen, der eine relaxtere Behandlung von Unicodeproblemen ermöglicht (angefangen mit der von der Wahrheitsfront hoch gepriesenen Entscheidung für 7-Bit-ASCII). Sag mir keiner, daß das nicht möglich ist - C kann es seit ca. 250 Jahren, oder? Nochmal, ich wiederhole das eingangs gesagte: es ist schon DER RICHTIGE WEG ZUM GLÜCK (TM), entsprechende Umlaut-Fehler zu bereinigen - es ist nur häufig völlig unangemessener Aufwand verglichen mit dem tatsächlichen Ziel des Menschen, der da was hinschreibt. Wenn ich ein Logfile analysiere, brauche ich wirklich KEINE WARNING NACH STDERR, weil ich in einem KOMMENTAR (um himmels willen!) einen Umlaut habe (und ja, ich schreie dies). Für eine nicht leere Menge an Problemen ist es mir völlig wurscht, ob das ü als ? erscheint - das bin ich als jahrelanger FreeAgent aus dem Usenet eh gewohnt ;) Da sind wir dann bei der alten Geschichte mit den Exceptions & den Fehlercodes - nennt mich Hanswurst, aber es gibt Fehler, die man ignorieren KANN. (Es gibt sogar Fehler, die man ignorieren SOLLTE, wie jede nichttriviale zwischenmenschliche Beziehung dich lehren wird). Um ein Beispiel aus der Physik zu gebrauchen: eine Quantenmechanische Betrachtung ist auch richtiger, "näher an der Wahrheit dran" als eine in der klassischen Mechanik ala Newton. Trotzdem kann man in einen Baumarkt gehen & einen Hammer erstehen & damit wehrlose Nägel erschlagen, ohne zuvor komplexe Berechnungen über Wahrscheinlichkeitsverteilungen, abgesehen solche volkswirtschaftlicher Art betreffs des Geldbeutelinhalts, erstellt zu haben. Unicode ist das eine Gebiet in Python, wo die Sprache von ihrer pragmatischen Handhabung "als richtig erwiesener Konzepte" abweicht (anders als z.B. in der Handhabung der "Objektorientierung", anders als die nicht minder frustrierende Java-Alles-Ist-Eine-Klasse-Wozu-Gibt-Es-Static-Schule) Nix für ungut, Gerson ps. Noch was fällt mir dazu ein: Wie wäre es, wenn Python verlangen würde, daß der Programmierer neben dem Programm auch einen mathematischen Beweis seiner Richtigkeit ablieferte? (Sowas ähnliches wurde ja vor 30-20 Jahren mal angestrebt). Per Definition würde das die Qualität der Python-Programme verbessern - und doch will das doch (hoffentlich) kein Mensch. Warum nur? Wollen die alle schlechte Programme haben? _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Gerson Kurz wrote:
Da sind wir dann bei der alten Geschichte mit den Exceptions & den Fehlercodes - nennt mich Hanswurst, aber es gibt Fehler, die man ignorieren KANN.
Ich hoffe, du erwartest nicht von Python, dass es dir die Entscheidung darueber abnimmt, welche Fehler das sind? Und was genau "ignorieren" im Einzelfall heisst? Der Entwickler weiss immer noch selber am besten, wie sein Programm in verschiedenen Situationen reagieren soll. Wenn du es einigermassen flexibel haben willst, dann kannst du dir leicht etwas von der folgenden Art basteln. def flex_encode(u, enc='iso-8859-1', replace=None, fmt=None): if replace != None and fmt != None: raise ValueError, '"replace" und "fmt" nur einzeln zulaessig' if type(u) == type(''): return u # potentiell gefaehrlich! try: return u.encode(enc) except UnicodeError: sl = [] for uc in u: o = ord(uc) if o < 128: # ascii sl.append(chr(o)) else: try: sl.append(uc.encode(enc)) # passt in's charset except UnicodeError: if replace: sl.append(replace) # ersetzen elif fmt: sl.append(fmt % ord(uc)) # konvertieren return ''.join(sl) # Anwendung: utest = unicode('abcäöü¤', 'iso-8859-15') # z.B. fuer Logfiles:
print flex_encode(utest) # unpassende zeichen ignorieren "abcäöü" print flex_encode(utest, replace='?') # ersetzen "abcäöü?" print flex_encode(utest, fmt='\\x%x') # konvertieren "abcäöü\x20ac"
# fuer HTML:
print flex_encode(utest, fmt='&#%d;') "abcäöü€"
Das ist natuerlich nicht fuer lange Texte optimiert, aber mit etwas gesundem Menschenverstand wird sicher jeder eine fuer die jeweilige Problemstellung angemessene Loesung hinkriegen.
Unicode ist das eine Gebiet in Python, wo die Sprache von ihrer pragmatischen Handhabung "als richtig erwiesener Konzepte" abweicht (anders als z.B. in der Handhabung der "Objektorientierung"
Wenn ich einen Unicode-Text in ein Charset konvertiere, und es befinden sich danach Zeichen ausserhalb dieses Charsets drin, dann ist das eindeutig falsch. Die pragmatische Loesung besteht darin, ein solches Verhalten zu verhindern. Im Gegensatz dazu sind die Wahlmoeglichkeiten objektorientiert vs. prozedural zu programmieren grundsaetzlich beide "richtig". Hier besteht die pragmatische Loesung deshalb darin, beide Mogelichkeiten zuzulassen. -schorsch -- Georg Mischler -- simulations developer -- schorsch at schorsch com +schorsch.com+ -- lighting design tools -- http://www.schorsch.com/ _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Georg Mischler wrote:
def flex_encode(u, enc='iso-8859-1', replace=None, fmt=None): if replace != None and fmt != None: raise ValueError, '"replace" und "fmt" nur einzeln zulaessig' if type(u) == type(''): return u # potentiell gefaehrlich! try: return u.encode(enc) except UnicodeError: sl = [] for uc in u: o = ord(uc) if o < 128: # ascii sl.append(chr(o)) else: try: sl.append(uc.encode(enc)) # passt in's charset except UnicodeError: if replace: sl.append(replace) # ersetzen elif fmt: sl.append(fmt % ord(uc)) # konvertieren return ''.join(sl)
Diese beiden Methoden (replace und fmt) lassen sich auch über den neuen Codec-Error-Callback-Mechanismus von 2.3 lösen (siehe PEP 293): class Replace(object): def __init__(self, replace): self.replace = replace def __call__(self, exc): return (self.replace*(exc.end-exc.start), exc.end) class Fmt(object): def __init__(self, fmt): self.fmt = fmt def __call__(self, exc): return (self.fmt % ord(exc.object[exc.start]), exc.start+1) import codecs codecs.register_error("gmreplace", Replace(u"XXX")) codecs.register_error("gmfmt", Fmt(u"\\x%x")) utest = u'abc\xe4\xf6\xfc\u20ac'
utest.encode("latin-1", "gmreplace") 'abc\xe4\xf6\xfcXXX'
utest.encode("latin-1", "gmfmt") 'abc\xe4\xf6\xfc\\x20ac'
print flex_encode(utest) # unpassende zeichen ignorieren
"abcäöü"
print flex_encode(utest, replace='?') # ersetzen
"abcäöü?"
print flex_encode(utest, fmt='\\x%x') # konvertieren
"abcäöü\x20ac"
# fuer HTML:
print flex_encode(utest, fmt='&#%d;')
"abcäöü€"
Das geht auch mit utest.encode("latin-1", "xmlcharrefreplace") [...] Bis demnächst, Walter Dörwald _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Gerson Kurz wrote:
Deshalb ist es mein Vorschlag, einen Parameter einzuführen, der eine relaxtere Behandlung von Unicodeproblemen ermöglicht (angefangen mit der von der Wahrheitsfront hoch gepriesenen Entscheidung für 7-Bit-ASCII). Sag mir keiner, daß das nicht möglich ist - C kann es seit ca. 250 Jahren, oder?
Möglich ist es schon. Es wird aber mit Sicherheit nicht durchgeführt, wenn es keiner implementiert. Python ist freie Software - es verbessert sich nur dadurch, dass jemand seine Freizeit opfert (oder das Geld seiner Arbeitgeber), und konkrete Verbesserungen vorschlägt und implementiert. Zu dieser Implementierung gehört vermutlich auch eine Menge "social engineering", um alle Leute zu überzeugen, dass die vorgeschlagene Änderung auch tatsächlich eine Verbesserung ist. Das lässt sich vielleicht am besten durch ein "opt-in" erreichen. Außerdem gehört Geduld dazu: Dieses Feature könnte frühestens in Python 2.4 angeboten werden, und auch nur dann, wenn in Kürze mit der Implementierung angefangen wird. Ciao, Martin _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
participants (9)
-
daniel.poelzleithner -
Georg Mischler -
Gerhard Häring -
Gerson.Kurz＠t-online.de -
Jens Kubieziel -
Martin v. Loewis -
martin＠v.loewis.de
-
Olaf 'ruebezahl' Radicke -
Walter Dörwald