Mailman 3 June 2017 - python-de

Re: [Python-de] Unittests vs Monitoring-Checks
by Bernd Waterkamp 24 Jun '17

24 Jun '17

Moin, Marcel Hellkamp schrieb: > On 06/23/2017 10:31 AM, Thomas Güttler wrote: >> Meinst du, dass die Health-Checks getestet werden wie alle anderen >> Code-Bereiche auch? > > Richtig. Sie sind Teil der API eines Dienstes und werden genau so > entwickelt und getestet wie alle anderen Kernfunktionen auch. Falls der Health-Check auch die Erreichbarkeit benötigter Dienste (Datenbanken, Queues, andere REST-Schnittstellen, ...) prüft, ist es sehr ratsam auch zu testen, ob der wirklich auf "rot" geht, wenn der Dienst nicht da ist. Das klingt so banal, aber nichts ist - insbesondere wenn Automatismen wie Restarts oder Alarme dran hängen - schlechter als nicht funktionierende Checks... Das geht ja fließend über in das Thema Resilienz/Robustheit der Anwendung: Erholt die sich z.B. davon, wenn die DB mal kurz nicht da war? Man muss ja nicht gleich größere Geschütze wie Pumba[0] oder die Simian Army[1] nehmen. Einfach mal Container/Prozesse killen und gucken was passiert. Aus dem gleichen Grund sollte man seine Checks so stricken, das die auch anschlagen, wenn die Überwachung selbst in einen Timeout läuft. Wenn irgendwas gar nicht läuft, bekommt man das schnell mit. Aber nichts ist fieser als Dienste die Antworten "verschlucken" oder nur sporadisch langsam antworten. Apropos benötigte Dienste: Kubernetes unterscheidet aktiv (liveness) und einsatzbereit (readyness). Letzteres kann genutzt werden, um zu schauen ob auch alles da ist was die Anwendung braucht. Die Unterscheidung wird eben relevant, wenn ich das automatisiert interpretieren möchte. Restarts der Applikation helfen zur Wiederherstellung des Betriebs nix, wenn die ein Problem hat, weil sie ihr Backend nicht erreicht. >> Nimmst du ein Framework, oder sind es einfache Scripte die in >> Nagios-typischer Weise 0, 1, 2 oder 3 zurückliefern? > > Bei einem REST-Service würde man z.B. eine "/api/health" Ressource > implementieren, die json zurück gibt. Noch was banales, das gerne vergessen wird: Genau wie bei einer guten REST-API sollte zusätzlich zum Status-Code auch ggfs. ein erklärender Text zurückgegeben werden. Fehlermeldungen, Link auf Doku, Ansprechpartner, etc. Das soll und darf maschinenlesbare Statuscodes nicht ersetzen, hilft aber oft weiter, das Problem schneller zu finden. > Das geht in die Richtung Service-Discovery und > Konfigurations-Management: Dabei meldet jeder Dienst (oder sein > Deploy-Job) während des Starts selbständig bei einer zentralen Stelle, > was für ein Dienst er ist und welche Schnittstellen er anbietet. Der > Monitoring-Server lauscht auf Änderungen in dieser Datenbank und > konfiguriert den Monitoring-Dienst wenn nötig automatisch neu. Wenn man möchte lauscht da auch der Proxy-Server (Backend hinzufügen bzw. entfernen), die Tools für das Operating usw. Für weitere Anregungen hier ein Vortrag von der Euro-Python: https://ep2016.europython.eu/media/conference/slides/service-discovery-for-… Das Thema wird erheblich aus dem Cloud- und Container-Umfeld getrieben, weil es da völlig normal ist, das Instanzen kommen und gehen. Beides ist aber keine Voraussetzung. Wir bauen (im Java-Umfeld) gerade in einer "normalen" Server-Umgebung was mit Consul, damit man für neue Instanzen möglichst wenig manuell anfassen muss. Auch da kann man sich verrennen[2], aber das Risiko gehört dazu. :-) Grüße, Bernd [0] https://hackernoon.com/pumba-chaos-testing-for-docker-1b8815c6b61e [1] https://github.com/Netflix/SimianArmy/wiki [2] https://xkcd.com/1319/

1 0

Re: [Python-de] Frage zu IDLE
by Hermann Riemann 23 Jun '17

23 Jun '17

Am 25.05.2017 um 21:58 schrieb Stefan Schwarzer: > On 2017-05-25 17:51, Hermann Riemann wrote:> Die ersten beiden Zeilen sind dann >> >> #!/usr/bin/python3 >> >> # -*- coding: utf-8 -*- >> wobei ich vermute, das die 2.Zeile nicht mehr notwendig ist. > genau: > > https://docs.python.org/3/whatsnew/3.0.html > > ... > PEP 3120: The default source encoding is now UTF-8. > ... Danke, ich habe auf aktuellen Rechner diese Zeilen entfernt mit: #!/usr/bin/python3 import os,sys def no_utf(name): if len(name)<5: return n=name.rfind('.') if n<0 or name[n+1:]!='py': return try: f=open(name) l=f.readlines() f.close() except: print("cannot read",name) return if len(l)<2: return line1=l[0].rstrip() line2=l[1].rstrip() if line1!="#!/usr/bin/python3": return f=open(name,"w") for i,line in enumerate(l): if i==1 and line.rstrip()=="# -*- coding: utf-8 -*-": continue f.write("{}\n".format(line.rstrip())) f.close() def was_denn(name): if os.path.islink(name): name1=os.path.realpath(name) if os.access(name,os.F_OK): name=name1 else: print("{} für {} existiert nicht".format(name1,name)) return if os.path.isdir(name): for inf3 in os.walk(name): ordner_name=inf3[0] for datei_name in inf3[2]: no_utf("{}/{}".format(ordner_name,datei_name)) else: no_utf(name) for arg in sys.argv[1:]: if os.access(arg,os.F_OK): was_denn(arg) continue print(arg+" gibt es nicht") Hermann der nicht nur zur Python einrücken manchmal folgendes Programm verwendet: #!/usr/bin/python3 import os, sys, string filenames=[] def pyr(filename): if not os.access(filename,os.F_OK): print(filename,"existiert nicht") return f=open(filename) l=f.readlines() f.close() for i,t in enumerate(l): l[i]=t.rstrip() while len(l)>0 and len(l[-1])==0: l.pop() os.system("cp -p {} {}~".format(filename,filename)) first_blanks=level=0 f=open(filename,"w") for z in l: if len(z)<3 or z[:2]!="#$": if first_blanks==0: f.write(z) elif first_blanks >0: f.write(first_blanks*' ') f.write(z) elif len(z) < first_blanks: print(-first_blanks,z) f.write(z) else: f.write(z[-first_blanks:]) f.write('\n') continue c=z[2] if c=='<': level-=1 elif c=='>': level+=1 elif c==')': level=0 first_blanks=3*level f.close() for arg in sys.argv[1:]: if arg[0]=='-': pass filenames.append(arg) for filename in filenames: pyr(filename) -- http://www.hermann-riemann.de

1 0

Unittests vs Monitoring-Checks
by Thomas Güttler 23 Jun '17

23 Jun '17

Hallo, seit vielen Monaten nutze ich TDD (Test Driven Development). Nicht immer, aber meistens gehe ich nach dem Prinzip "Red, Green, Refactor" vor. Bei der Entwicklung ist zusammen mit CI (Continuous Integration) alles prima. Jetzt gibt es aber noch einen anderen Bereich: Monitoring-Checks. Also Prüfungen, die nicht im Rahmen vom CI passieren, sondern Prüfungen, die für produktive Systeme sind. Wir nutzen dafür ein Nagios-ähnliches Tool, wie wohl die meisten Menschen, die für die Verfügbarkeit von Systemen verantwortlich sind. Derzeit gibt es hier einen großen Bruch. Entwickler schreiben Unittests flüssig und regelmäßig. Genauso locker und leicht hätte ich gerne das Erstellen neuer Checks. Damit es kein einseitiges pro/contra zu meinem Lösungsvorschlag gibt, stelle ich hier erst mal das Problem vor - ohne Lösungsansatz. Erste Frage: Könnt ihr nachvollziehen, wenn ich mir das wünsche? Genauso locker und leicht hätte ich gerne das Erstellen neuer Checks. Zweite Frage: Wie läuft das bei euch mit Checks: Entwicklung, Deployment, Ausführung, Weiterleitung, ...? Gruß, Thomas -- Thomas Guettler http://www.thomas-guettler.de/

2 5

ANN: Python Meeting Düsseldorf - 28.06.2017
by eGenix Team: M.-A. Lemburg 22 Jun '17

22 Jun '17

________________________________________________________________________ ANKÜNDIGUNG Python Meeting Düsseldorf http://pyddf.de/ Ein Treffen von Python Enthusiasten und Interessierten in ungezwungener Atmosphäre. Mittwoch, 28.06.2017, 18:00 Uhr Raum 1, 2.OG im Bürgerhaus Stadtteilzentrum Bilk Düsseldorfer Arcaden, Bachstr. 145, 40217 Düsseldorf Diese Nachricht ist auch online verfügbar: http://www.egenix.com/company/news/Python-Meeting-Duesseldorf-2017-06-28 ________________________________________________________________________ NEUIGKEITEN * Bereits angemeldete Vorträge: Matthias Endler "Grumpy - Python to Go source code transcompiler and runtime" Tom Engemann "BeautifulSoup als Test framework für HTML" Jochen Wersdörfer "Machine Learning: Kategorisierung von FAQs" Linus Deike "Einführung in Machine Learning: Qualitätsprognose aus Sensordaten erstellen" Andreas Bresser "Bilderkennung mit OpenCV" Philipp v.d. Bussche & Marc-Andre Lemburg "Telegram Bot als Twitter Interface: TwitterBot" Weitere Vorträge können gerne noch angemeldet werden: info(a)pyddf.de Allerdings wird vermutlich bei diesem Treffen kein Platz mehr sein, sondern erst beim nächsten Mal im 27.09.2017. * Startzeit und Ort: Wir treffen uns um 18:00 Uhr im Bürgerhaus in den Düsseldorfer Arcaden. Das Bürgerhaus teilt sich den Eingang mit dem Schwimmbad und befindet sich an der Seite der Tiefgarageneinfahrt der Düsseldorfer Arcaden. Über dem Eingang steht ein großes "Schwimm' in Bilk" Logo. Hinter der Tür direkt links zu den zwei Aufzügen, dann in den 2. Stock hochfahren. Der Eingang zum Raum 1 liegt direkt links, wenn man aus dem Aufzug kommt. Google Street View: http://bit.ly/11sCfiw ________________________________________________________________________ EINLEITUNG Das Python Meeting Düsseldorf ist eine regelmäßige Veranstaltung in Düsseldorf, die sich an Python Begeisterte aus der Region wendet: * http://pyddf.de/ Einen guten Überblick über die Vorträge bietet unser YouTube-Kanal, auf dem wir die Vorträge nach den Meetings veröffentlichen: * http://www.youtube.com/pyddf/ Veranstaltet wird das Meeting von der eGenix.com GmbH, Langenfeld, in Zusammenarbeit mit Clark Consulting & Research, Düsseldorf: * http://www.egenix.com/ * http://www.clark-consulting.eu/ ________________________________________________________________________ PROGRAMM Das Python Meeting Düsseldorf nutzt eine Mischung aus (Lightning) Talks und offener Diskussion. Vorträge können vorher angemeldet werden, oder auch spontan während des Treffens eingebracht werden. Ein Beamer mit XGA Auflösung steht zur Verfügung. (Lightning) Talk Anmeldung bitte formlos per EMail an info(a)pyddf.de ________________________________________________________________________ KOSTENBETEILIGUNG Das Python Meeting Düsseldorf wird von Python Nutzern für Python Nutzer veranstaltet. Um die Kosten zumindest teilweise zu refinanzieren, bitten wir die Teilnehmer um einen Beitrag in Höhe von EUR 10,00 inkl. 19% Mwst, Schüler und Studenten zahlen EUR 5,00 inkl. 19% Mwst. Wir möchten alle Teilnehmer bitten, den Betrag in bar mitzubringen. ________________________________________________________________________ ANMELDUNG Da wir nur für ca. 20 Personen Sitzplätze haben, möchten wir bitten, sich per EMail anzumelden. Damit wird keine Verpflichtung eingegangen. Es erleichtert uns allerdings die Planung. Meeting Anmeldung bitte formlos per EMail an info(a)pyddf.de ________________________________________________________________________ WEITERE INFORMATIONEN Weitere Informationen finden Sie auf der Webseite des Meetings: http://pyddf.de/ Mit freundlichen Grüßen, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Jun 22 2017) >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>> Python Database Interfaces ... http://products.egenix.com/ >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ ________________________________________________________________________ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/

1 0

Python in wine?
by Hartmut Goebel 19 Jun '17

19 Jun '17

Hallo zusammen, ich versuche, Python in wine zum Laufen zu bringen. Das Ziel ist, den Bootloader von PyInstaller innerhalb wine mit waf und VC++ zu bauen. Dazu versuche ich Python 2.6.1 zu installieren, aber die Version ist mir eigentlich egal, solange waf damit kann. Meine Installations-Kommandos sind: rm -rf /home/vagrant/.wine sh ./winetricks win8 dotnet46 wine python-3.6.1-amd64.exe PrependPath=1 SimpleInstall=1 InstallAllUsers=0 Die Installation schlägt jedoch fehl i299: Plan complete, result: 0x0 i300: Apply begin i010: Launching elevated engine process. i011: Launched elevated engine process. e000: Error 0x80004005: Failed to set pipe to non-blocking. e000: Error 0x80004005: Failed to connect to elevated child process. e000: Error 0x80004005: Failed to actually elevate. e000: Error 0x80004005: Failed to elevate. i399: Apply complete, result: 0x80004005, restart: None, ba requested restart: No Ich habe bereits verschiedene Optionen für python-3.6.1-amd64.exe ausprobiert, ebenso den Web-Installer, wine mit und ohne mono und/oder dornet462. Irgendwelche Tipps? -- Schönen Gruß Hartmut Goebel Dipl.-Informatiker (univ), CISSP, CSSLP, ISO 27001 Lead Implementer Information Security Management, Security Governance, Secure Software Development Goebel Consult, Landshut http://www.goebel-consult.de Blog: http://www.goebel-consult.de/blog/dsl-fernkonfiguration-ist-kritisch-fur-de… Kolumne: http://www.cissp-gefluester.de/2010-07-passwoerter-lieben-lernen

2 3

PyCon.DE 2017 - Call for Proposals
by Mike Müller 19 Jun '17

19 Jun '17

Hallo Python-Freunde, das ist unser Aufruf zu Beiträgen für die PyCon.DE 2017. Da wir uns für Englisch als Konferenz-Sprache entschieden haben, ist dieser auf Englisch. Call for Proposals ------------------ The Call for Proposals for the PyCon.DE 2017 is open until July 30, 2017. Please submit your proposals here: https://www.papercall.io/pyconde2017 We’re looking for proposals on every aspect of Python: programming from novice to advanced levels, applications and frameworks, or how you have been involved in introducing Python into your organization. PyCon.DE is a community conference and we are eager to hear about your experience. The conference will be held in English language only. The conferences addresses: * Data Scientists * Software Developers * System Administrators * Academic Scientists * Technology Enthusiasts We are looking for: * 30 minute presentations (incl. optional 5 minute Q&A) * 45 minute presentations (incl. optional 5 minute Q&A) PyData @ PyConDE 2017 There will be a PyData track at this year’s conference. Please submit your papers for the PyData track through the PyConDE form. About PyCon.DE 2017 ------------------- The next PyCon.DE will be held October 25 - 27, 2017 at the ZKM - Center for Art and Media in Karlsruhe, Germany [1]. The conference is the sixth in this series, gathering Python professionals and enthusiasts. The conference language will English, attracting Pythonistas from all over Europe and the world. Volunteers organize and provide talks, tutorials, as well as discussions in an open-source fashion. This Karlsruhe conference has a special focus on data science. Therefore, a PyData conference is held as part of PyCon.DE. PyData [2] is an internationally renowned conference series, which is dedicated to data science, machine learning, and AI. The ZKM - Center for Art and the Media is a unique cultural institution, as it is a place that extends the original tasks of the museum. It is a home of all media and genres, a house of both the traditional arts like painting, photography, and sculpture as well as the time-based arts such as film, video, media art, music, dance, theater, and performance. Conference registration is open. Don't miss this event! More information available at: http://www.pycon.de [1] http://zkm.de [2] http://pydata.org

1 0

Re: [Python-de] Diskussion Python Module
by Erich Schnoor 19 Jun '17

19 Jun '17

Bemerkungen zum posting von Hans-Peter Jansen am 18.06.2017: Sehr geehrte Herr Jansen, was Sie schreiben mag alles richtig sein, aber für mich nicht relevant. Ich beschäftige mich seit 1998 mit kryptographischen Problemen und habe für meinen Algorithmus auch ein Patent erhalten. Die von Ihnen zitierten AES-Modi: CCM, EAX, CGM und OCB) haben eine interne Schwäche: Alle Eingaben und Ausgaben erfolgen in einem einheitlichen System: im 8-bit Modus. Damit müssen sie früher oder später auch gebrochen werden können. Zum Verständnis meiner Auffassung lesen Sie doch bitte meinen Artikel: http://www.telecypher.net/Kryptographie_Neue_Funktionen.pdf Mit internetten Grüßen Ernst Erich Schnoor

1 0

Diskussion Python Module
by Erich Schnoor 18 Jun '17

18 Jun '17

Hallo, Pythonfreunde auf dieser maillist bin ich neu. Ich wundere mich, dass es so wenig Diskussionen um Python Module gibt. Liegt es daran, dass so wenig Module entwickelt werden oder gibt es schon nichts Neues mehr, das noch diskutiert werden kann? Meinen Beitrag zur Diskussion findet Ihr unter: http://www.telecypher.net(Telepython.pdf Mit internetten Grüßen Ernst Erich Schnoor eschnoor(a)multi-matrix.de

3 2

Re: [Python-de] Diskussion Python Module
by Erich Schnoor 18 Jun '17

18 Jun '17

Peter Otten wrote: . . . . . . . . . Wie ich sehe, haben Sie diesmal den Quellcode mitgeliefert - wenn auch in einem absolut unüblichen Format und mit mindestens einem Bug (zchn nirgendwo definiert, soll wahrscheinlich zeichen heißen). . . . . . . . . . Richtig, vielen Dank für den Hinweis. Ist inzwischen korrigiert. Mit internetten Gtüßen Ernst Erich Schnoor

1 0

Diskussion Python Module
by Erich Schnoor 17 Jun '17

17 Jun '17

Entschuldigung! in meinem Posting muss es natürlich heissen: http://www.telecypher.net/Telepython.pdf Ernst Erich Schnoor eschnoor(a)multi-matrix.de

1 0