Mailman 3 - python-de

[Python-de] Files Zugriff unter WINDOWS2000, (Löschen von Dateien mit permission denied)
by Josef Cihal 12 Nov '02

12 Nov '02

Ich möchte unter Windows 2000 Dateien löschen, auch die an welche zugegriffen wird... Es geht aber nicht! Bertiebssystem erlaubt es nicht... Die Files liegen auch einer Linux Maschine, aber ich kann nicht das Skript dort laufen lassen und ...rc = os.popen("rm -fR %s" %os.path.join(aMmiFolder, aFile))... benutzen, weil ein Teil von Skript arbeitet mit win32process library... Gibt es eine möglichkeit, wie kann man diese Files überschreibne , bzw. löschen und anlegen unter Window -Platform??? Vielen Dank für jede Idee! lg josef _______________________________________________ Python-de maillist - Python-de(a)starship.python.net http://starship.python.net/mailman/listinfo/python-de

3 4

Processs Management Problem
by Josef Cihal 12 Nov '02

12 Nov '02

Ich habe ein Process Management Problem: Ablauf: 1. Start vom Process 1 2. Nachdem Process 1 fertig ist darf der nächste gestartet werden. Process= ist ein Python Skript... Danke für jede Idee... (mit execv geht es nicht... )>>> rc = os.execv("Z:\\make_mmi.py",()) Traceback (innermost last): File "<stdin>", line 1, in ? OSError: [Errno 8] Exec format error lg josef Mein Versuch: aProcess = win32process.CreateProcess( None, aCmd, None, None, 0, win32process.NORMAL_PRIORITY_CLASS, None, None, win32process.STARTUPINFO() ) i = 1 while 1: rc = win32process.GetExitCodeProcess(aProcess[0]) if rc <> STILL_ACTIVE: break time.sleep(1) if i == 30: try: win32process.TerminateProcess(aProcess[0],0) except win32process.error, x: print x break i = i + 1 _______________________________________________ Python-de maillist - Python-de(a)starship.python.net http://starship.python.net/mailman/listinfo/python-de

3 2

Deutsche Unicode-FAQ
by Gerson.Kurz＠t-online.de 12 Nov '02

12 Nov '02

ch habe eine deutschsprachige Erläuterung zu Unicode erstellt. Sie ist unter http://p-nand-q.com/e/unicode-faq-de.html verfügbar. Ich freue mich auf Kritik (natürlich nicht wirklich, aber das sagt man halt so ;); wenn es nichts mehr zu bemängeln gibt, kann ich auch eine Englische Version dazu basteln. Ich denke, ich weiß jetzt auch, wo meine Probleme mit Unicode lagen: - Die Vorstellung "Strings sind Arrays von Char-Elementen", die von Nicht-Unicode-Sprachen genährt wird. (15 Jahre Assembler und C/C++ gehen nicht spurlos an einem vorbei). Siehe auch den entsprechenden Abschnitt in der FAQ. - Die Vorstellung "Unicode-Strings sind Arrays von short", die aus meinen Erlebnissen mit dem Win32-API resultiert (10 Jahre Windows gehen nicht spurlos an einem vorbei). Siehe auch den entsprechenden Abschnitt in der FAQ. - Die unsaubere Ausdrucksweise, die man beispielsweise auf www.unicode.org findet ("How Unicode differs from other encodings" oder in der MSDN "Unicode is a worldwide character-encoding standard that uses 16-bit code values to represent all the characters used in modern computing", verbunden mit meiner Manie, solche Aussagen korinthenkackerisch zu interpretieren ;) Beide Aussagen sind nach meinem jetzigen Verständnis nämlich eigentlich falsch, auch wenn sie von hochoffiziösen Quellen stammen. Ciao, Gerson _______________________________________________ Python-de maillist - Python-de(a)starship.python.net http://starship.python.net/mailman/listinfo/python-de

9 9

[Python-de] Unicode - Bläue (Umlaute mit Absicht im Header)
by Gerson.Kurz＠t-online.de 11 Nov '02

11 Nov '02

Ich muß mich mal wieder mit Unicode rumärgern, wobei der Ärger einerseits aus meiner zugegebenermaßen sehr oberflächlichen Kenntnis von Unicode resultiert, andererseits aus dem Wetter. Also. Ich habe "Strings", die von OLE (genauer Outlook) stammen. Die Strings enthalten Umlaute - z.B. das Paradebeispiel "Persönliche Ordner". Ich möchte die Datei so schreiben, daß mein Linux (genauer, mbox-basierte Mehler) die Dateien lesen können. Die Outlook-Strings haben "<type 'unicode'>". Meine Oldskool-Lang-Lebe-Der-Amiga-1985-(Naturgemäß-nur-der-Amiga1000-mit-US-Tasta tur-und-Kickstart1.3)-Zeichensatzkenntnisse sind: Bytes sind Bytes. Du kannst die Bytes unter Windows wegschreiben, und unter Linux reinnudeln. Wenn aus dem Byte ein "ü" wird, dann liegt das am Zeichensatz: im Prinzip kann man sich 'ne Codepage sparen, wenn man den richtigen Font hat. Ein Byte ist einfach nur eine Zahl. Im März 2002 hatte ich schon mal was geschrieben, und auch meine Unicode-Kenntnisse zusammengefasst, unter <news:3c846d80.95456984@news.isar.de> (oder Google Groups suche nach "Python Unicode Blues"). Dank der damaligen Antworten von Martin von Loewis konnte ich mir folgendes zusammenbasteln: -------------------------------------------- self.fh = open(filename,"wb") self.fh.write( codecs.BOM_LE ) def ist_es_nicht_grausam(schmarrn_elender): self.fh.write(schmarrn_elender.encode("utf-16le")) ja_wirklich_es_ist_grausam = ist_es_nicht_grausam ... ja_wirklich_es_ist_grausam( string_den_ich_von_outlook_bekam ) ... self.fh.close() -------------------------------------------- Prima, funktioniert einwandfrei. Frage 1: Warum muß ich den "<type 'unicode'>" noch mal als Unicode encoden? Der Laie würde sagen das ist doch redundant? Frage 2: Angenommen, ich möchte im String "<" durch "<" ersetzen. Möglichkeit a) schmarrn_elender = str(schmarrn_elender).replace("&","<") Möglichkeit b) schmarrn_elender = cgi.escape(schmarrn_elender) Beide Möglichkeiten werfen wunderprächtige Exceptions, wenn der prima tolle Unicodestring Umlaute enthält ;( - die beliebten Ordinal not in range fehler; sind also eigentlich keine Möglichkeiten, wie wir Philosophen meinen. Frage 3: Angenommen, es ist mir egal, ob in China geborene Suaheliindianerdichterfürsten Mundartpoeme von Win nach Lin exportieren können - ich möchte einfach ein "ö" 8-bit abspeichern, und 8-bit unter Linux einlesen, unter der Voraussetzung gleiche Codepage. Das ist ja z.B. der Fall, wenn ich mit dem popeligen Notepad ein "ö" speichere. Es kann also nicht völlig jenseits des Menschenmöglichen sein, oder? Zumal ja mbox AFAIK auch ganz simples 8-Bit Dateiformat ist, und ich habe gehört, daß auch unter Linux der eine oder andere schon mal Mehl mit Umlauten gelesen haben soll (angeblich - ich mag mich irren). Frage 4: Gibt es ein, äh, UNICODE-Tutorial? Nun ja, es gibt http://www.reportlab.com/i18n/python_unicode_tutorial.html (faszinierenderweise das erste Ergebnis, wenn man Google mit "Unicode Tutorial" quält), welches aber nicht die diversen Formate *erklärt*, sondern einfach nur Codeschnipsel hinwirft. Ich würde (nicht wirklich) das ganze mal *verstehen*, das muß doch möglich sein? Ach ja, mir ist entfernt bewusst, daß es sowas wie Mimeencoding von Umlauten z.B. in Mailheadern gibt - (und ich hoffe auf ein entsprechendes Püdong-Modul dazu), aber es geht z.B. auch um Verzeichnisse - ich würde gerne die Vz-Struktur meines 2Gb-Outlook-pSts in "die neue Welt" rüberretten, und zumindest KMail scheint das ja zu können. Frage 5: btst #6,$bfe001 bne.s "Frage 5" (Kleiner Scherz am Rande) _______________________________________________ Python-de maillist - Python-de(a)starship.python.net http://starship.python.net/mailman/listinfo/python-de

12 13

Oracle Treiber
by Eckhard Lehmann 10 Nov '02

10 Nov '02

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 08 Nov '02

08 Nov '02

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 07 Nov '02

07 Nov '02

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 06 Nov '02

06 Nov '02

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 05 Nov '02

05 Nov '02

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 01 Nov '02

01 Nov '02

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