Mailman 3 November 2002 - python-de

Oracle Treiber
by Eckhard Lehmann Nov. 10, 2002

Nov. 10, 2002

Hallo Liste, ich bin relativ neu bei Python, hatte bisher eher mit Perl und Java zu tun. Umso mehr bin ich allerdings von Python begeistert, ich find das Konzept und die Sprache klasse :o). Gibt es für Python auch einen Oralce- Treiber bzw. eine Oracle API im Stile von python-pgsql oder python-pygresql für PostgreSQL? Bzw. gibt es eine andere Möglichkeit, eine Oracle Datenbank anzusteuern? Das wär mir ziemlich wichtig, dabei ist es auch egal ob kommerziell oder nicht (wobei frei erhältlich natürlich besser wäre ;). Danke schonmal, Eckhard _______________________________________________ Python-de maillist - Python-de(a)starship.python.net http://starship.python.net/mailman/listinfo/python-de

3 3

Isch habe verstanden
by Gerson.Kurz＠t-online.de Nov. 8, 2002

Nov. 8, 2002

Ich weiß, ich weiß, ihr stöhnt sicher jetzt: kann der Depp nicht die Finger davon lassen, wenn er es nicht versteht? Warte es ab! Also, ich habe das Programm (http://p-nand-q.com/python/out2xml.zip) jetzt erstmal funktionsfähig, und mir folgendes vermutlich fehlgeleitete Verständnis erarbeitet. # Zeichen sind jeweils zwei Byte lang (Little Endian) UNICODE_ENCODING = "utf-16le" # Zeichen sind normalerweise ein Byte lang, Sonderzeichen per "Escapesequenz" auf mehrere Bytes verteilt. UNICODE_ENCODING = "utf-8" # Zeichen sind jeweils ein Byte lang, Interpretation erfolgt abhängig von der Codepage. Wenn das Zeichen nicht in ein Byte (0..255) passt, gibt es eine Exception. UNICODE_ENCODING = "latin-1" - Ein Unicodestring "weiß", daß in "Höher" das zweite Zeichen als "Kringel mit zwei Punkten drüber" dargestellt werden soll. - Es gibt nicht nur eine Abbildung "Kringel mit zwei Punkten drüber" als Bytes. - Deshalb muß ich encode() aufrufen, und erhalte dann aus dem "Wissenden Unicodestring" einen Bytebatzen in diesem Encoding. Beispiel (und da, glaube ich, habe ich es verstanden): >>> test = u"ö" >>> test u'\x94' >>> test.encode("utf-16le") '\x94\x00' >>> test.encode("utf-8") '\xc2\x94' >>> test.encode("latin-1") '\x94' >>> test.encode("ascii") Traceback (most recent call last): File "<stdin>", line 1, in ? UnicodeError: ASCII encoding error: ordinal not in range(128) >>> Das erklärt meine Fragen 1 (der String *weiss nicht* welches Encoding er hat), und 2 (weil das genau der Zweck von encode ist) und 3 (weil es eben kein kanonisches Encoding gibt). Das erklärt auch, warum ich das Encoding z.B. in XML Starttag angeben muß, weil sonst der Leser (Das ominöse Notepad) nicht weiß, was er von z.B. '\xc2\x94' zu halten hat. Juhu! Oder? _______________________________________________ Python-de maillist - Python-de(a)starship.python.net http://starship.python.net/mailman/listinfo/python-de

4 3

Unicodefragen klarer gestellt
by Gerson Kurz Nov. 7, 2002

Nov. 7, 2002

Also, vielleicht oder sogar mit an Sicherheit grenzender Wahrscheinlichkeit war ich gestern nicht auf der Höhe meiner Gelassenheit und habe deshalb die Ungelassenheit der Antworten provoziert. Vorbemerkung: Ich benutze PythonWin 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32. Nach ein bischen Analyse habe ich folgendes gesehen. Die von COM gelieferten Unicodestrings sehen beispielsweise so aus: Dump of 26 Bytes for attrib 'name' of <type 'unicode'> $00000000 4F72646E 65722022 47656CF6 73636874 65204F62 Ordner "Gel.schte Ob $00000014 6A656B74 6522 jekte" Das wäre übrigens die richtige Antwort auf meine Frage: "warum muß ich den Unicode-String nochmal encoden" gewesen: weil das natürlich kein utf-16le ist, die Datei aber utf-16le enthalten soll. Frage 1) <frage>Wo ist das Encoding dieses Strings festgelegt?</frage> Das 'F6' entspricht dem 'ö' in der deutschen Codepage, ich glaube aber ziemlich sicher zu wissen, daß dem in z.B. Frankreich 'F6' nicht als 'ö' angezeigt wird. Adieu, schöne Unicodeweltvorteile? Ursprünglich hing ich der Illusion an: Unicode = Jedes Zeichen wird als zwei Bytes abgespeichert. Diese Illusion wurde genährt durch Unicode am Win32-API unter C: entweder hat man Unicode nicht definiert, dann ist "CHAR char", oder man hat Unicode definiert, dann ist "CHAR short"; sprich aus CHAR szName[1860] wird short szName[1860] usw. usf. Damit kommt man (gut, vielleicht nicht "man", aber zumindest: ich) eigentlich auch relativ gut zurecht. Wenn ich mir aber Dump of 26 Bytes for attrib 'name' of <type 'unicode'> $00000000 4F72646E 65722022 47656CF6 73636874 65204F62 Ordner "Gel.schte Ob $00000014 6A656B74 6522 jekte" anschaue, so ist es ja zumindest an den Bytes nicht *inherent offensichtlich*, daß es sich um Unicode handeln soll, und nicht um plain old "was kümmert mich der Chinese mir san Bayern" Bytes wie wir sie aus C-Code kennen und lieben. (Um Fragen ob der Qualität des Hexdumps vorzubeugen, habe ich ein entsprechendes Codeschnipsel unten angehängt) Frage 2) <frage>Der Datentyp wechselt von "unicode" auf "str", wenn man ..encode aufruft. Warum?</frage> Beispiel: >>> test = u"\x6c\xf6" # das "lö" von oben >>> test u'l\xf6' >>> type(test) <type 'unicode'> >>> type(test.encode("utf-16le")) <type 'str'> >>> Das ist mir so aufgefallen: ich hatte, zum Zwecke besseren Verständnisses meiner "warum nochmal encode, wenn schon unicode"-Frage, folgendes eingebaut: output( hexdump(attrib) ) attrib = attrib.encode("utf-16le") output( hexdump(attrib) ) und erhielt folgendes: Dump of 26 Bytes (type <type 'unicode'>) $00000000 4F72646E 65722022 47656CF6 73636874 65204F62 Ordner "Gel.schte Ob $00000014 6A656B74 6522 jekte" Dump of 52 Bytes (type <type 'str'>) $00000000 4F007200 64006E00 65007200 20002200 47006500 O.r.d.n.e.r. .".G.e. $00000014 6C00F600 73006300 68007400 65002000 4F006200 l...s.c.h.t.e. .O.b. $00000028 6A006500 6B007400 65002200 j.e.k.t.e.". Leichte Unsicherheit beschleicht mich, wenn ich sehe, daß aus dem ach so problematischen "F6" einfach ein "F600" wird. Ich kann mir nicht vorstellen, daß das Unicodekonsortium aus ehemaligen Nazis besteht, die die Deutsche Sprache so sehr bevorzugen, daß bei der Umwandlung "unicode mit 8-bit-zeichen" zu "unicode mit 16-bit-zeichen" der Bytecode beibehalten wird, während sich der Franzmann mit komischen Riesenzeichen rumschlagen muß. Oder? Um es noch genauer zu formulieren: daß aus "4F" ein "4F00" wird, ist zu erwarten, weil "4F" im Bereich 7-Bit-ASCII liegt. Aber "F6" liegt ja in der Grauzone 128-255, ich würde also erwarten, "F6" wird zu sagen wir "1234" und nicht nur zu "F600". Frage 3) <frage>Warum exceptions, wenn ich einen Unicode-String binär abspeichern möchte?</frage Folgendes: >>> test u'l\xf6' >>> f = file("test.txt","wb") >>> f.write(test) Traceback (most recent call last): File "<interactive input>", line 1, in ? UnicodeError: ASCII encoding error: ordinal not in range(128) Warum "warum": ich habe "wb" angegeben, und würde erwarten, daß keine gesonderte Interpretation stattfindet, sondern einfach die Binärdaten weggeschrieben werden. Schliesslich kann ich ja anhand von >>> print map(ord,test) [108, 246] sehen, daß beide Zeichen "in ein Byte passen". Und daher übrigens auch folgende Hardcore-Lösung für mein Problem >>> mit_dem_hammer_programmieren = lambda x: "".join(map(chr,map(ord,x))) >>> f.write(mit_dem_hammer_programmieren(test)) Und das ist ja genau das, was ich in diesem Fall machen möchte. * EINSCHUB: Zur letzteren Frage habe ich inzwischen eine Antwort in Marcs' pdf-Vortrag gefunden: Es soll helfen, bei der Migration auf Unicode Fehler zu identifizieren (""BDFL" entscheidet default encoding ist ASCII weil "Helps identify the problem areas in programs"). Gut, ich hätte noch mehr Fragen dazu, aber ich will nicht zu sehr die Geduld der geneigten Antworter provizieren, deshalb Schluß damit. Jetzt noch vielleicht zu den Fragen und Antworten auf mein vorheriges Schriftwerk. Ich hatte geschrieben: > Bytes sind Bytes. ... Ein Byte ist einfach nur eine Zahl. Martin v. Loewis schreibt: > Diese Kenntnisse erlischen natürlich in dem Moment, wo man mehr als > 256 Zeichen haben will. Ab dann gilt: Zahlen sind Zahlen. Falsch, Zahlen sind Mengen, wie Russell 1910 versucht hat nachzuweisen. OK, Scherz beiseite, natürlich sind Zahlen Zahlen. Das ändert aber nichts an meiner Aussage. Um deutlicher zu machen, was ich meine: Der Computer (der Assembler) bearbeitet Bytes. Er kann auch Gruppen von 2 oder 4 oder 8 Bytes bearbeiten, aber normalerweise bearbeitet er Bytes. Computer sind dumm und kommunistisch: jedes Byte ist gleich. Wenn das Byte zufällig $f6 ist, dann ist das ein Byte wie andere - daß ich als Mensch anstelle des $F6 ein 'ö' sehen will, ist mein humanes Problem, das kümmert den Computer erstmal garnicht. Daß das $f6 ein 'ö' sein soll ist eine Frage der *Interpretation*. Ich *interpretiere* die Bytes mit einer Codepage (mit einem Font), so daß ich am Bildschirm einen Kreis mit zwei Punkten drüber sehe - der Computer kennt kein 'ö', der Computer kennt $f6. Jetzt gibt es Länder, in denen es sagen wir mal 2000 Schriftzeichen gibt (Japan vielleicht). Das ändert nichts daran, daß der Computer weiterhin stupide ein um das andere Byte hin-und-herschiebt. Wenn der Japaner sein Zeichen mit der Nummer 1860 abbilden will, dann kann er das nicht in einem Byte machen, sondern muß dafür zwei Bytes hernehmen. Da wären wir wieder bei meiner "Unicode = Jedes Zeichen wird als zwei Bytes abgespeichert". Ich werde das Gefühl nicht los, daß die "wir basteln ein optimiertes Unicode-Encoding, wo 'viele' Zeichen als Bytes abgespeichert werden, und der komische europäische Sonderzeichenmüll aus zwei (oder IIRC gar drei) Zeichen abgesetzt wird" nicht völlig optimal ist, da sie die Komplexität der Unicodebehandlung gegenüber "Unicode = Jedes Zeichen wird als zwei Bytes abgespeichert" erheblich erhöht. Ich schrub: > Du kannst die Bytes unter Windows wegschreiben, und unter Linux > reinnudeln. Martin v. Loewis schrab: > Klar. Allerdings ist dann ein ü nicht mehr unbedingt ein ü. Ja. Daß ist auch heute schon der Fall - das ist sogar der Fall, wenn ich eine Datei von einem deutschen Windows auf ein deutsches OS/2 übertrage. Zitat aus meinen C++-Quälcodes: #ifdef TARGET_IS_OS2 #define AE "" #define ae "" #define OE "" #define oe "" #define UE "" #define ue "" #define ss "á" #elif defined(TARGET_IS_WIN32) #define AE "Ä" #define ae "ä" #define OE "Ö" #define oe "ö" #define UE "Ü" #define ue "ü" #define ss "ß" #endif Damit habe ich aber erstmal kein Problem, ich will ja einfach *meine* Daten von Windows nach Linux bringen, und ich möchte in diesem Zusammenhang nicht gleichzeitig meine Muttersprache von Deutsch auf Chinesisch ändern. Ich schrüb: > Frage 1: Warum muß ich den "<type 'unicode'>" noch mal als Unicode encoden ? > Der Laie würde sagen das ist doch redundant? Martin v. Loewis schräb: > Ganz einfach: Zahlen sind nicht Bytes. Zahlen sind Zahlen. Will man > Zahlen in Bytes umrechnen, gibt es mehrere Möglichkeiten (utf-16be, > utf-16le, utf-8, ...) Äh, das Beispiel kann ich nicht ganz verstehen. Die Hexzahl 0xF63A ist genau eine Zahl (wenn man mal vom Thema Endianess absieht), und zwar z.B. Dual 11110110 00111010. Ich sehe nicht, wo ich da was umrechne. Vielleicht paßt die Zahl nicht in ein Byte, und ich muß deshalb zwei Bytes nehmen - es gibt aber eigentlich nur eine Umrechnung "zahl - byte" Umrechnen tue ich, wenn ich die Information "ich möchte einen Kringel mit zwei Punkten drüber als einzelnes Zeichen ausgeben" als 0xF6 abspeichere. Mein Fehler war die Illusion: Es gibt mit Unicode genau eine kanonische Umrechnung "alle zeichen dieser Welt" <-> "Bytebatzen". Dazu merkt der pdf-Vortrag von M.-A. Lemburg richtig an, daß es mehrere solche Umrechnungen gibt. M.-A. Lemburg ist ferner ein geschrieben Habender: > Python nimmt per default an, daß Zeichen in > normalen Strings ASCII-kodiert sind. Umlaute gehören nicht > dazu. Alles andere als eine Exception, die ja schließlich zum > Nachdenken anregen soll, würde nur in Datenmüll resultieren. Äh, das nimmt es bei *Unicode* an, nicht bei *normalen* Strings. Beispiel: >>> f = open("test.txt","wb") >>> f.write( "l\xf6" ) >>> f.write( u"l\xf6" ) Traceback (most recent call last): File "<interactive input>", line 1, in ? UnicodeError: ASCII encoding error: ordinal not in range(128) Und an dieser Stelle wieder mein Verständnisproblem. Wenn überhaupt, hätte ich mir die Exception bei einfachen Strings erwartet, und nicht bei Unicode. Nach folgender Logik: der Einsatz von Unicode soll mich ja eigentlich jeglichen Nachdenkens über Sanskrit entheben. Tatsächlich muß ich aber, um Unicode sinnvoll einsetzen zu können, hier wie mir scheint erhebliche Nachdenkarbeit leisten. M.-A. Lemburg wird immer ein geschrieben Habender sein: http://www.egenix.com/files/python/Unicode-EPC2002-Talk.pdf Danke, das bringt mich schon ein bischen weiter. (Zum Beispiel habe ich da gesehen, warum die Exception bei Unicode auftritt und nicht bei Strings). Nun gut, das Problem ist identifiziert, fehlt nur noch die Lösung ;) ---------- Vorsicht, Codeschnipsel auf der Fahrbahn -------- def hexdump(data): global printable_chars addr, bytes, ascii = "$00000000", [' '] * 20, [' '] * 20 result = cStringIO.StringIO() print >>result, "Dump of %d Bytes (type %s)" % (len(data), type(data)) for i in range(len(data)): byte = ord(data[i]) bytes[i%20], ascii[i%20] = "%02X" % byte, printable_chars[byte] if i%4 == 3: bytes[i%20] += " " if (i % 20) == 19: print >>result, addr, ''.join(bytes), ''.join(ascii) addr, bytes, ascii = "$%08X" % (i+1), [' '] * 20, [' '] * 20 i = len(data) if i and (i % 20) <> 0: print >>result, addr, "%-45s" % ''.join(bytes).strip(), ''.join(ascii) return result.getvalue() printable_chars = ['.'] * 256 for __c in "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 !\"$:;-#+*%&/()=?'": printable_chars[ord(__c)] = __c _______________________________________________ Python-de maillist - Python-de(a)starship.python.net http://starship.python.net/mailman/listinfo/python-de

2 1

Berliner Pythontreffen
by Peter Gerlach Nov. 6, 2002

Nov. 6, 2002

From: Stephan Diehl <stephan.diehl(a)gmx.net> To: python-de(a)python.net Subject: Re: [Python-de] Berliner Python-Treffen 08.11.02 Date: Wed, 6 Nov 2002 10:39:02 +0100 Reply-To: python-de(a)starship.python.net On Wednesday 06 November 2002 03:09, you wrote: >> Liebe Ortsgruppe, >> > > >>> > ########################################################### >>> > # Am Freitag, den 8. November 2002 findet das nächste # >>> > # Berliner Python-Treffen statt, # >>> > # # >>> > # wieder in der Räumen der GraS GmbH, Heilbronner Str. 10,# >>> > # 10711 Berlin, 2. Stock, 18:00. # >>> > ########################################################### >> >> >> >> > Also ich kaume auch. Peter Gerlach http://www.way2python.de _______________________________________________ Python-de maillist - Python-de(a)starship.python.net http://starship.python.net/mailman/listinfo/python-de

1 0

Re: [Python-de] Re: [Python-de]Py magazine (was: Zeitschriftenart ikel zu Python?!)
by Stephan Diehl Nov. 5, 2002

Nov. 5, 2002

On Tuesday 05 November 2002 10:40, you wrote: > Hi, > > wie kommst du auf 20 Euro ? Obwohl ich ein Jahresabo habe, kostet auch die > einzelausgabe 5 Dollar. Das wars. Nach Ausgabe zwei sind leider die Preise erhöht worden. Das steht hier: http://www.pyzine.com/subscribe.phtml (Ich wollt es auch nicht glauben, als ich das gelesen habe) > > mfg Marc gehling > > -----Originalnachricht----- > Von: Stephan Diehl > An: python-de(a)python.net > Gesendet: 05.11.02 10:14 > Betreff: [Python-de] Re: [Python-de]Py magazine (was: Zeitschriftenartikel > zu Python?!) > > On Monday 04 November 2002 18:35, you wrote: > > Hat jemand erfahrung mit dem Py-Magazine? wollte ich schon laenger > > abbonieren ... > > Py ist ganz nett, allerdings kommt mir der neue Preis doch etwas hoch > vor. So > gut, dass man ca. 20 Euro (international) pro Exemplar bezahlen möchte, > ist > es dann doch nicht. > > Stephan > > > gruessle, > > > > holger > > _______________________________________________ > Python-de maillist - Python-de(a)starship.python.net > http://starship.python.net/mailman/listinfo/python-de _______________________________________________ Python-de maillist - Python-de(a)starship.python.net http://starship.python.net/mailman/listinfo/python-de

1 0

JavaScript in HTML-Seiten
by Dinu Gherman Nov. 1, 2002

Nov. 1, 2002

Hallo, ich analysiere HTML-Code von einer Site, die Teile davon aber mit JavaScript in einzelnen Frames erzeugt. Diese kann man auch nicht getrennt laden. Da urllib.urlopen() von JavaScript na- tuerlich keinen Plan hat, geht's an der Stelle nicht weiter... Ich will das nicht auf Teufel komm raus loesen, aber es stellen sich doch ein paar abgefahrene Fragen, z.B.: - gibt es ueberhaupt einen JavaScript-Interpreter, der nicht mit einem Webbrowser fest verbandelt ist? - bietet evtl. Mozilla eine Schnittstelle, ueber die man den Code der aktuellen Seite abgreifen kann? - hat Grail jemals JavaScript beherrscht? Dinu -- Dinu C. Gherman ...................................................................... "Questions are never indiscreet. Answers sometimes are." (Oscar Wilde) _______________________________________________ Python-de maillist - Python-de(a)starship.python.net http://starship.python.net/mailman/listinfo/python-de

3 2

Re: [Python-de] ftpmirror anders herum
by Stefan Schwarzer Nov. 1, 2002

Nov. 1, 2002

Hallo Stephan, Stephan Diehl wrote: >> > weiss zufällig jemand, ob es irgendwo ein python script gibt, dass wie >> > ftpmirror funktioniert, aber einen lokalen Verzeichnisbaum auf einen ftp >> > server kopiert? >> > (Bevor jemand fragt: ja, ich habe Google befragt) >> >> es gibt auf meiner Website ein Skript upload.py >> -> http://www.sschwarzer.net/python/python_software.html >> >> Es ist nicht besonders elegant, ist eher aus meinen Python-Anfangstagen ;-) >> Wenn ich heute nochmal sowas machen wollte, würde ich als Basis ftputil >> nehmen (auch auf der Seite, ist deutlich neuer). Schau's dir mal an. :) > > Nach vielen Mühen hatte ich deine Tools auch so gefunden (musste dann aber > weg, sonst hätt ich das ja schon gepostet :-) > Das "upload" script hat mir leider gar nicht gefallen, Schade, musst du das denn hier so öffentlich sagen? ;-) > aber mit "ftputil" war > es gar nicht so schwer, ein kleines Mirrorscript zu erstellen. Ich werd es > noch ein bisschen aufpolieren (so mit command line options) und es dann > posten. Prima! > Ich glaube, irgendetwas bei den "upload" und "upload_if_newer" methoden > funktioniert nicht so richtig, aber das muss ich noch genauer untersuchen. Es kann Probleme geben, wenn die "Zeitrechnung" auf Server und Client nicht übereinstimmt (verschiedene Zeitzonen; u. U. auch kleinere Abweichungen). Ich habe das in der Doku zumindest angedeutet. :-) Einige weitere Schwächen, wovon die meisten an den Beschränkungen des Parsens der DIR-Ausgabe liegen, sind in ftputil.txt erwähnt. Wenn du Fehler findest oder Verbesserungsvorschläge hast, bin ich dafür dankbar. > Lässt sich das ftputil modul nicht als Standardmodul in Python reinmogeln? > Ich glaube, dass das eine echte Bereicherung wäre. Hui, das höre ich gerne. :-) Ich werde erstmal auf comp.lang.python nach Meinungen fragen, bevor ich mich womöglich daran mache, ein PEP zu schreiben. Viele Grüße Stefan _______________________________________________ Python-de maillist - Python-de(a)starship.python.net http://starship.python.net/mailman/listinfo/python-de

2 1