Mailman 3 December 2007 - python-de

syncml client
by Alexander Hoffmann Jan. 24, 2008

Jan. 24, 2008

Hi, Ich habe vor, mir einen syncml-Client zu basteln, der Adressdaten von einem eGroupware-Server holt und lokal abspeichert. Normalerweise finde ich in kürzester Zeit für jedes halbwegs offene Protokoll eine Unterstützung in Python. Für syncml ist mir das nicht gelungen. Habe ich etwas übersehen, oder muss ich wirklich von Scratch anfangen (ja, ich weiss, es gibt, XML-Parser und vieles mehr). Wenn es wirklich noch nichts gibt, weiss jemand, ob ein syncml-Modul geplant ist ? Schöne Grüsse, Alex p.s. Frohe Weihnachten für Euch alle !

3 3

BER-TLV
by Rolf Zölcher Jan. 5, 2008

Jan. 5, 2008

Hallo zusammen, hat vielleicht jemand von Euch Erfahrung mit pyasn1? Ich möchte für ein EMV Projekt BER-TLV Strukturen folgender Art erzeugen und habe keine Ahnung wie ich das angehen kann. E221 // TAG E2 + Len DF060200A6 // MID für EAPS (=A6) DF600200A6 // Kartenart-ID (Poseidon = A6 : identisch mit MID) F115 // Tag F1 + Len F905DF2C02671F // F9 mit Präfix 671 F905DF2C02670F // Präfix 670 F905DF2C02490F / Präfix 490 Für jeden Hinweis wäre ich dankbar! Schöne Grüße, Rolf

2 5

feststellen ob ein prozess läuft
by robert rottermann Dec. 28, 2007

Dec. 28, 2007

Hallo, ich möchte feststellen, ob ein prozess noch läuft, von dem id die pzess-id kenne. z.Z. mache ich das so, dass ich mir mit ps alle prozesse ausgeben lasse, und dann scanne. gibt es da eine einfachere bzw bessere methode? danke für hinweise gruss & frohe festtage robert

8 15

obj.xyz <> obj['xyz']
by Roland M. Kruggel Dec. 27, 2007

Dec. 27, 2007

hallo liste, ich habe folgenden classe geschrieben <code> class Ob(object): def __init__(self, dic): for i in dic.keys(): setattr(self, i , dic[i]) def __repr__(self): return str(self.__dict__) def __getitem__(self, key): return self.__dict__.get(key,None) def __setitem__(self, key, value): setattr(self, key, value) def __delitem__(self, key): del self.__dict__[key] def __len__(self): return len(self.__dict__) def __iter__(self): return self.__dict__.iterkeys() def keys(self): return self.__dict__.keys() def has_key(self, key): return self.__dict__.has_key(key) </code> aufrufen tue ich das ganze mit xy = Ob({'aa':'a1', 'bb':'b1'}) ich kann somit xy['aa'] nutzen als auch xy.aa. Es funktioniert auch. aber: Wenn ich auf eine undefinierte variable zugreife "xy['undef']" bekomme ich, wie gewollt, ein None zurück. Jedoch ein "xx.undef" erzeugt den fehler Traceback (most recent call last): File "<string>", line 1, in <string> AttributeError: 'Ob' object has no attribute 'undef' Ein "xx.undef" ruft wohl nicht __getitem__ auf. Wie kann ich das lösen? -- cu Roland M. Kruggel mailto:rk.liste@bbf7.de http:www.bbf7.de System: Intel, Debian etch, 2.6.21, xfce4, KDE 3.5 ------------ Zufallszitat Wie man sein Kind nicht nennen sollte: Ron Dell

4 10

Re: [Python-de] web-framework
by Jochen Ritzel Dec. 24, 2007

Dec. 24, 2007

On Mon, 24 Dec 2007 15:48:30 +0100, Jochen Ritzel <THC_rulez(a)gmx.de> wrote: > Also ich habe lange Turbogears benutzt, finde aber mittlerweile Pylons > deutlich besser. > Turbogears ist gerade sehr im Umbruch, man will alles anders machen. Vor > allem aber will man Turbogears praktisch zu Pylons umbauen! Beide > Projekte (TG und Pylons) wollen so etwas wie "Pylons + das Widget System > von TG" werden. > (Turbogears will auf Buffet,SQLAlchemy und Paster umsteigen ... das ist > genau Pylons! Und Pylons benutzt im Gegenzug schon Komponenten von TG > und will eben auch Widgets) > > Hauptgrund für meinen Umstieg war vor allem, dass Kid, die default > Template Engine von TG, in der auch alle Widgets geschrieben sind, viel > zu langsam für mein konkretes Projekt war. Zuerst hatte ich (in TG) Kid > durch Cheetah ersetzt und so das Speed Problem gelöst. Allerdings war > damit auch die Widgets dahin. Also warum nicht gleich zu Pylons, wenn > mich schon nichts mehr bei TG hält? > > Bereut hab ich den Umstieg nicht, im Gegenteil: SQLAlchemy gefällt mir > besser als SQLObject, Paster besser als CherryPy, Mako besser als Kid > und die (berüchtigten, von RubyonRails portierten) Webhelper von Pylons > sind nochmal ein Bonus. Auch die Doku von Pylons ist wirklich > ausgezeichnet, mit vielen How-Tos. > >

2 1

UDP Pakete vollständig vom socket lesen wenn die Länge vorher nicht bekannt ist?
by Bastian Venthur Dec. 14, 2007

Dec. 14, 2007

Hi Liste, ich versuche über einen Socket UDP Pakete zu lesen. Nach meinem Verständniss kommen UDP Pakete doch immer ganz (vollstädig) oder garnicht an oder? Wie lese ich also vollständige Pakete von einem socket, wenn ich vorher nicht weis wie lang sie sind? Früher habe ich immer socket.recv(LEN) gemacht und für LEN einen Wert gesetzt der hoffentlich größer als jedes Paket was je eintreffen wird ist. Sollte das nicht auch eleganter gehen? Ich denke da an eine Schleife die solange vom Socket liest bis keine Daten mehr kommen (was dann hoffentlich dem Paketende entspricht). Nen Testcode den ich rasch geschrieben hab sieht so aus: class Dispatcher(asyncore.dispatcher): def __init__(self, port): asyncore.dispatcher.__init__(self) self.create_socket(socket.AF_INET, socket.SOCK_DGRAM) self.bind(('', port)) def writable(self): return False def handle_read(self): data = '' while True: d = '' try: d = self.recv(4) except: print "Ooops, something went wrong reading the socket." if d: data += d else: break print data def handle_connect(self): pass if __name__ == "__main__": d = Dispatcher(8080) asyncore.loop() So wie ich asyncore.handle_read verstanden habe, sollte das nur aufgerufen werden wenn neue Daten am Port lesbar sind, also wenn ein neues Paket eingetroffen ist. Nun versuche ich solange Daten vom Socket zu lesen bis nix mehr kommt, was ich ganz naiv als Paketende interpretiere. Ich habe bewusst eine sehr kleine Buffersize von 4 gewählt damit ich testen kann. Wenn ich nun Daten an den besagten Port schicke deren Länge <= 4 ist scheint alles zu klappen, aber bei längeren Daten werden immer nur die ersten vier bytes empfangen. Weis jemand Rat? Schöne Grüße, Bastian -- Bastian Venthur http://venthur.de Debian Developer venthur at debian org

2 1

probleme mit threads die nicht zum zug kommen -- vermutlich pygame.Clock.tick() schuld?
by Bastian Venthur Dec. 12, 2007

Dec. 12, 2007

N'abend Liste, ich habe ein Programm das mit vier Threads arbeitet und bemerke immer mal wieder (wie das bei nebenläufigen Anwendungen halt so ist) eigenartige Fehler die darauf hinweisen, dass mindestens ein Thread scheinbar nicht mehr zum Zug kommt. Es handelt sich nicht um einen Deadlock oder etwas in der Richtung, das Problem löst sich irgendwann auch wieder von alleine auf, aber es darf trotzdem nicht passieren ;) Hier mal der grobe Aufbau der Threads * T1: blockierendes empfangen von UDP Daten über socket in einer Endlosschleife. Die Daten gehen ziemlich genau mit 25Hz ein und sind Pakete die ein paar Hundert Byte groß sind. * T2: blockierendes empfangen von UDP Daten auf einem zweiten Port in einer Endlosschleife. Die Pakete sind hier auch recht klein und kommen nur alle paar Minuten an Die obigen beiden Treads basteln etwas an den Empfangenen Daten herum (nicht CPU intensiv und ziemlich fix) und packen das Ergebnis in eine Queue (meine Eventqueue) * T3: Abarbeiten der Queue in einer Endlosschleife (auch sehr fix) * T4: (vermutlich der Übeltäter) eine Endlosschleife in der pygame.Clock.tick() aufgerufen wird. In dieser Schleife passieren eigentlich auch keine rechenintensiven Sachen, tick(60) gibt immernoch 16ms zurück! Im Grunde bin ich etwas verwundert dass manchmal manche Threads sekundenlang nicht zum Zug kommen, da eigentlich alles mit max mit 25Hz durchlaufen wird und dabei auch nichts rechen- oder IO-Intensives passiert. Und 25Hz ist doch eigentlich sehr langsam oder?! Wenn ich bei Clock.tick() eine Framerate von 60Hz wünsche tritt das Problem recht häufig auf, bei moderateren 25Hz eher selten. Ich hab gelesen, das ein time.wait(10) kurz vor oder nach einem Clock.tick() helfen soll, weil die CPU dann mal kurz freigegeben wird. Ich find das aber etwas hack'ish und würde ne sauberere Lösung bevorzugen. Ich hab mich ein bisschen zu Threads in Python eingelesen und erfahren, dass es keine wirkliche Nebenläufigkeit gibt, da Python nur einen Prozessor benutzt. Erschreckend, aber ok. Ich könnte die ersten drei Threads zur Not zu einem Zusammenfassen indem ich asyncore benutze. Erste Frage: ist asyncore CPU intensiv? Oder besser: CPU intensiver als zwei threads die jeweils blockierend auf einem Port lauschen? Und dann bleibt noch die Frage ob das wirklich das Problem beheben würde oder nur das Risiko vermindert. Ich glaube weniger als zwei Threads gehen bei dieser Anwendung wirklich nicht, einmal die pygame-loop und einmal meine Netzwerkschleife die nebenbei Daten empfangen muss. Ich weis meine Infos sind nicht sehr konkret, aber hat vielleicht jemand ne Ahnung was hier schief läuft oder ne Idee wie ich das Problem umschiffen könnte? Schöne Grüße, Bastian -- Bastian Venthur http://venthur.de Debian Developer venthur at debian org

1 0

Sechstes Usertreffen in München
by Marek Kubica Dec. 10, 2007

Dec. 10, 2007

Servus, Das letzte Usertreffen ist noch keinen Monat her, aber nach der langen Pause sind wir nun um so motivierter den grob monatlichen Zyklus nun wieder aufzugreifen. Um den Weihnachtsstress etwas zu entzerren haben wir uns entschieden es eine Woche vorzuverlegen. Daher kündige ich heute schon das sechste Usertreffen in München an, welches wieder an einem Donnerstag stattfindet und zwar am Donnerstag, den 13.12.2007 um 18:30. Wir werden auch diesmal wieder die Räumlichkeiten der Ludwig Maximilians Universität nutzen, somit steht uns ein Beamer und ein Internetzugang zur Verfügung. Dieses mal gibt es einen Vortrag zu der in Python geschriebenen Python-Implementation PyPy[1] von Georg Brandl. Es wird sicherlich interessant, da die Zusammenhänge nicht ganz einfach zu erklären sind aber PyPy ein durchaus spannendes, zeitweise von der EU gesponsortes Projekt ist. Die Folien vom letzten Vortrag über Pygame sowie Links zu einigen besprochenen Themen finden sich im Wiki verlinkt. Für das leibliche Wohl ist auch gesorgt, nach dem Treffen gibt es die Möglichkeit eine nahegelegene Pizzeria aufzusuchen. Stattfinden wird es am Institut für Informatik der Ludwig-Maximilians-Universität München, Oettingenstr. 67, Raum Z 1.09 (Zentralbereich in der Mitte des Gebäudes, 1. OG). Da der Raum nicht ganz einfach zu finden ist, wäre es gut, wenn sich Interessierte vorher bei mir per Mail melden. Man kann natürlich auch einfach so vorbeikommen, je nach dem ob man gerade Zeit hat. Informationen gibt es wie immer im Wiki. Also bis dann, Marek [1] http://codespeak.net/pypy/ [2] http://www.ifi.lmu.de/Kontakt/Verkehrsanbindung/index.html [3] http://wiki.python.de/User_Group_M%C3%BCnchen

1 1

Raumänderung: nächstes Treffen von pyCologne am 12.12.2007 18:30 Uhr
by Christopher Arndt Dec. 10, 2007

Dec. 10, 2007

Achtung Raumänderung: Am 12.12. steht der Raum 0.14 im RRZK-B ausnahmsweise nicht zur Verfügung. Stattdessen wurde der Raum 1.08 im gleichen Gebäude, 1. Etage reserviert: Hier nochmal die korrigierten Daten: Datum: Mittwoch, den 12.12.2007 Uhrzeit: 18:30 Uhr c.t. Ort: Raum 1.08 , 1. Etage, Benutzerrechenzentrum (RRZK-B) der Universität Köln, Berrenrather Str. 136, 50937 Köln Christopher Arndt

1 0

ANN: nächstes Treffen von pyCologne am 12.12.2007 18:30 Uhr
by Christopher Arndt Dec. 10, 2007

Dec. 10, 2007

Hallo liebe Pythonfreunde, das nächste Treffen von pyCologne, der Python User Group Köln, findet statt: Datum: Mittwoch, den 12.12.2007 Uhrzeit: 18:30 Uhr c.t. Ort: Pool 0.14, Benutzerrechenzentrum (RRZK-B) der Universität Köln, Berrenrather Str. 136, 50937 Köln Programm: * Vortrag über das Composite Pattern (Entwurfsmuster Kompositum) von Ralf Schönian * Ausgewählte Themen aus einem Python-Einführungskurs von Rebecca Breu Ab ca. 20:30 Uhr werden wir den Abend gemütlich in einem nahe gelegenen Restaurant/Kneipe ausklingen lassen oder einen Weihnachtsmarkt besuchen. Weitere Information zu pyCologne, inkl. Wegbeschreibung, Fotos und Protokollen vergangener Treffen usw., findet ihr auf unserer Seite im deutschen Python Wiki: http://wiki.python.de/pyCologne Bis bald, Christopher Arndt

1 0