Mailman 3 October 2017 - python-de

Berliner PUB-/DZUG-Treffen am 17.9. um 19 h im newthinking store
by Dinu Gherman 04 Sep '22

04 Sep '22

Liebe Python-Freunde, diesen Donnerstag, den 17.8.2009 (übermorgen!) findet wieder ein PUB/DZUG-Treffen (Python und Zope User Group in Berlin) statt. Ort und Zeit sind wie immer: 19 Uhr, im newthinking store [1]. Anschließend wird das Treffen wieder im Restaurant Tucholsky [2] fortgesetzt. Zur Planung der Restaurantkapazitäten bitte ich euch ein Häckchen in der Doodle-Umfrage [3] zu machen, wenn ihr an- schließend noch mitkommen wollt. Das Programm muss dieses mal etwas kurzfristig arrangiert werden. Wer also schon immer mal einen kurzen Vortrag halten wollte, z.B. zu einem der Themen im Python-Wiki [4] und diesen womöglich schon in der Schublade hat, der (oder die) ist herzlich dazu eingeladen. Dann bitte bei mir vorher kurz per E-Mail ankündigen! Ansonsten werden einige, die auf der DZUG-Tagung letzte Woche in München waren, locker darüber berichten. Dabei ging es unter an- derem über die kommenden Versionen 4 und 5 von Plone. Sehr wahr- scheinlich wird Veit dazu Prospekte verteilen. Eine weitere Idee besteht darin, locker Buchempfehlungen zu den Themen Python/Zope/Plone auszutauschen, was man am besten macht, indem man das jeweilige Buch auch zum Treffen mitnimmt. Ich werde am Donnerstag das Buch "Python for Linux and Unix System Admini- stration" [5] dabei haben. Liebe Grüße und bis Donnerstag, Dinu PS: Ich übernehme mit Veit bis auf Weiteres die Organisation die- ser Treffen von Stephan, der das bisher vorbildlich gemacht hat, aber nun seinen väterlichen Aufgaben höhere Priorität geben wird. Nochmals vielen Dank, Stephan - ich hoffe, Du kannst trotzdem noch vorbeischauen! [1] newthinking store, Tucholskystr. 48, 10117 Berlin, http://newthinking-store.de [2] Restaurant Tucholsky, Torstraße 189, 10115 Berlin, http://www.restauration-tucholsky.de [3] http://doodle.com/rwqizz6ewxk6iscw [4] http://wiki.python.de/User%20Group%20Berlin [5] http://www.oreilly.de/catalog/9780596515829 ...................................................................... Follow me on Twitter: http://twitter.com/dinugherman

2 1

Sentry vs Nagios
by Thomas Güttler 21 Oct '17

21 Oct '17

Hallo, angeregt durch die letzten hilfreichen Posts habe ich mir Sentry etwas genauer angeschaut. Es sieht wirklich gut aus. Ich habe das im Team besprochen und nun stellt sich die Frage: Sentry vs Nagios Es kamen Bedenken auf, dass man langfristig nicht mit zwei Tools arbeiten will. Es wäre schön eine Oberfläche zu haben in der man sieht ob irgendwo etwas klemmt. Wie siehst du das? Gruß, Thomas -- Thomas Guettler http://www.thomas-guettler.de/ I am looking for feedback: https://github.com/guettli/programming-guidelines

3 3

Re: [Python-de] Sentry vs Nagios
by Bernd Waterkamp 20 Oct '17

20 Oct '17

Diez B. Roggisch schrieb: > Ich halte das für eine fehlgeleitete Diskussion. Dito. > Sentrys Stärke liegt in der Klassifikation von Stacktraces, und einer > guten Oberfläche und diese bewerten und abhandeln zu können. Genau dafür setzen wir es auch ein. Welche Funktionen man wo nutzt kann im Detail manchmal zu Diskussionen führen, aber grundsätzlich bin ich dafür, das man sich auf die jeweiligen Stärken konzentriert. Sentry und Nagios oder Icinga stehen daher auch für mich aus den genannten Gründen konkurrenzlos nebeneinander. Die Überschneidung ist ziemlich gering. Genauso würde ich nicht freiwillig größere Mengen Metriken mit einem Werkzeug auswerten wollen, wo das nur rudimentär möglich ist. Beispiel: Unser Logmanagement (Graylog) hat schon ein paar Auswertungsfunktionen dazu. Für größere Zeiträume, komplexere Fragen oder einfach Werte die nicht aus Logs stammen haben wir KairosDB. Das spricht aber nicht gegen Graylog oder Sentry, die einfach andere Aufgaben haben. Grüße, Bernd

1 0

Re: [Python-de] Bitte widersprechen
by Schmitt Uwe (ID SIS) 17 Oct '17

17 Oct '17

Wegen der Mehrsprachigkeit: Klar lernen die Kinder später fließen zu sprechen, aber der Unterschied ist meiner Erfahrung nach gering, und schlussendlich sprechen sie zwei Sprachen fließend, anstatt in einer nur herum zu stammeln. Gruss Uwe Schmitt ________________________________________ Von: python-de [python-de-bounces+uwe.schmitt=id.ethz.ch(a)python.org]" im Auftrag von "Stefan Ram [ram(a)zedat.fu-berlin.de] Gesendet: Dienstag, 17. Oktober 2017 20:05 An: python-de(a)python.org Betreff: Re: [Python-de] Bitte widersprechen Achim Domma <domma(a)procoders.net> writes: >- Learn one programming language, not ten: Du kennst "Pragmatic >Programmer"? Da wird eine Sprache pro Jahr als Minimum empfohlen. Das >würde ich auch so sehen. Wer nur eine oder zwei Sprachen kann, kann nur >in diesen Strukturen denken und hat in der Regel Scheuklappen an. Die einen nennen es "nur in diesen Strukturen denken und Scheuklappen anhaben", für die anderen ist "Thinking in Python" und "Vermeidung von nicht-idiomatischem Programmieren" etwas Erstrebenswertes. Auch Mehrsprachigkeit hat ihre Nachteile: »Infants who are raised in bilingual homes learned two similar-sounding words in a laboratory task at a later age than babies who are raised in homes where only ¯¯¯¯¯¯¯¯¯ one language is spoken.« www.eurekalert.org/pub_releases/2007-09/sfri-bri092407.php (Es könnte sein, daß diese URI von 2007 inzwischen nicht mehr zielführend ist.) _______________________________________________ python-de maillist - python-de(a)python.org https://mail.python.org/mailman/listinfo/python-de

1 0

Re: [Python-de] Bitte widersprechen
by Hermann Riemann 17 Oct '17

17 Oct '17

Am 17.10.2017 um 01:48 schrieb Stefan Ram: > Achim Domma <domma(a)procoders.net> writes: >> - Learn one programming language, not ten: Du kennst "Pragmatic >> Programmer"? Da wird eine Sprache pro Jahr als Minimum empfohlen. Nach welcher Auswahl? http://www.99-bottles-of-beer.net/abc.html >> Wer nur eine oder zwei Sprachen kann, kann nur >> in diesen Strukturen denken Ein echter Programmierer https://www.bernd-leitenberger.de/echte-programmierer.shtml programmiert in jeder Sprache FORTRAN >> und hat in der Regel Scheuklappen an. >> Javaentwickler können oft z.B. nur OO denken. Anfangs waren Klassen für mich auch nur schlechter Ersatz für Strukturen, und sind es teilweise auch noch. So verwende ich für Python Projekte class GLobal: und irgendwo g=Global() .. in denen ich alle globale Daten unterbringe, so das ich sie überall mit g.irgendwas ansprechen kann. ( das habe ich in C auch so gemacht, nur mit struct statt class) > Ich würde auf dem Gebiet der Anzahl der zu erlernenden > Programmiersprachen anderen Menschen keine Regeln vorgeben > wollen, Die Anzahl halte ich nicht für so wichtig wie die Auswahl. Ich meine lisp mit eval und quote sollte für fortgeschrittenen Programmierer dabei sein, damit man in dieser Methodik denken lernt. Ansonsten halte ich lisp für technisch überholt. > aber für mich selber würde ich es bevorzugen, mich > auf eine oder auf ganz wenige Sprachen konzentrieren zu können. Wenn ich zwischen C und Python hin und herspringe, versuche ich in C if a<b: a+=1; f(a) und in Python if (a<b){ f(++a);} Das ich Sprachen vollständig lerne, habe ich aufgegeben. Und bei Laufzeitfunktionen muss ich häufig nachschlagen, z.B. bei der Reihenfolge von Argumente. Der Sprachumfang von Python ist erheblich höher als der von C, aber mit einer Teilmenge davon lässt sich einfacher etwas machen. So habe ich erst vor wenigen Wochen den Nutzen von set bemerkt, obwohl ich schon viel Jahre meist Python verwendet habe. Wenn ich ein Kurs besuche, bekomme ich viel nicht mit, und vergesse auch viel. > (Aus praktischen Gründen muß ich derzeit mehr > Programmiersprachen [zumindest deren Grundlagen] > erlernen als mir eigentlich lieb ist.) Ich sehe das so. Eine Hauptprogrammiersprache ( meine historische Reihenfolge: Fortran :-| , Pascal :-( , C :-) , Python :-) ) Ein Programmiersprache für große Mengen und zeitkritische ( z.B. Grafik) Aufgaben ( bei mir C ) Sprachen die ich spezifisch verwende, ( bash für Konsole und javascript für browser) Sprachen die ich für spezielle Anwendungen brauchen könnte ( C++, LUA, perl, php, Assembler für Arm.., mini und micro Python) Sprachen die vielleicht etwas interessantes enthalten ( Ruby smalltatalk, ghc ..) Sprachen denen ich aus dem Weg gehe ( Java, Pascal.., COBOL ) Hermann der beruflich keine Programmiersprache mehr zu lernen braucht, und vermutet, das mittlerweile die meisten Bücher über Programmieren, die er in Buchläden sieht, von Python handeln. -- http://www.hermann-riemann.de

1 0

Uncaught Exception im Prod
by Thomas Güttler 17 Oct '17

17 Oct '17

Hallo, wenn eine unerwartete Exception im Produktivbetrieb auftritt, was macht ihr dann? Bisher sehe ich das in einem Logfile und diese Logfiles werden in einer Zentrale ausgewertet. Aber so langsam stößt das an seine Grenzen. Wie behandelt ihr Exceptions[1] im Prod? Gruß, Thomas [1] ich meine hier Exceptions die nicht mit try...except sinnvoll abgefangen werden :-) -- Thomas Guettler http://www.thomas-guettler.de/ I am looking for feedback: https://github.com/guettli/programming-guidelines

3 4

Re: [Python-de] Python-Kurs
by Christopher Arndt 17 Oct '17

17 Oct '17

Hi Stefan, Am 16.10.2017 um 14:22 schrieb Stefan Ram: > Ein erster Entwurf meines Python-Kurses: > > http://www.purl.org/stefan_ram/pub/python-kurs danke fürs Teilen. Auf wieviele Stunden/Tage ist der Kurs angelegt? Ich komme inzwischen zu der Überzeugung, dass für Programmieranfänger eher ein Ansatz wie beim Django Girls Tutorial [1] geeignet ist. D.h. man steigt gleich mit einem "real world"-Projekt ein und eignet sich die Grundlagen der benutzten Programmiersprache dabei an, ohne das alles im Detail methodisch-strukturiert durchzugehen. Zugegeben, auch der Django Girls Kurs kommt nicht ohne einen Informationdump zu Python-Sprachelementen aus (Abschnitt "Einführung in Python"), aber auch das würde ich in einem mehrtägigen Kurs auf maximal einen Tag beschränken, bzw. auf mehrere kleinere Exkurse aufteieln. Chris [1]https://tutorial.djangogirls.org/de/

1 0

Re: [Python-de] Bitte widersprechen
by Thomas Güttler 17 Oct '17

17 Oct '17

Am 17.10.2017 um 01:48 schrieb Stefan Ram: > Achim Domma <domma(a)procoders.net> writes: >> - Learn one programming language, not ten: Du kennst "Pragmatic >> Programmer"? Da wird eine Sprache pro Jahr als Minimum empfohlen. Das >> würde ich auch so sehen. Wer nur eine oder zwei Sprachen kann, kann nur >> in diesen Strukturen denken und hat in der Regel Scheuklappen an. >> Javaentwickler können oft z.B. nur OO denken. > > Ich würde auf dem Gebiet der Anzahl der zu erlernenden > Programmiersprachen anderen Menschen keine Regeln vorgeben > wollen, aber für mich selber würde ich es bevorzugen, mich > auf eine oder auf ganz wenige Sprachen konzentrieren zu können. > (Aus praktischen Gründen muß ich derzeit mehr > Programmiersprachen [zumindest deren Grundlagen] > erlernen als mir eigentlich lieb ist.) Na super. Dann sind wir doch genau einer Meinung. Bitte die Überschrift nicht aus den Augen verlieren: Das sind meine persönlichen Guidelines für mich. Ich mache sie nur öffentlich verfügbar. Insbesondere darum, damit man mich kritisieren kann. Ich versuche dann aus der Kritik Verbesserungsvorschläge abzuleiten. Klappt nicht immer, aber oft. Gruß, Thomas -- Thomas Guettler http://www.thomas-guettler.de/ I am looking for feedback: https://github.com/guettli/programming-guidelines

1 0

Re: [Python-de] Source code generation is a stupid idea
by Hermann Riemann 16 Oct '17

16 Oct '17

Am 13.10.2017 um 11:50 schrieb Thomas Güttler: > ich habe den Abschnitt "Source code generation is a stupid idea" > überarbeitet: > https://github.com/guettli/programming-guidelines/blob/master/README.rst#so… Wenn Du http://www.99-bottles-of-beer.net/language-common-lisp-114.html automatisch nach Python konvertieren würdest, könntest Du das Programm anschießend vielleicht auch verstehen. Hermann der der vermutet, wenn regexpr nach Python code (und nach Modifikation zurück) konvertiert würde, er derartige Ausdrücke besser debuggen könnte -- http://www.hermann-riemann.de

3 3

Re: [Python-de] Python-Kurs
by Reimar Bauer 16 Oct '17

16 Oct '17

Hi hier mal mein erster Eindruck. Im Dokument sind sehr viele PEP8 Fehler, wenn man schon anfängt das zu vermitteln, dann kann man damit als gutes Beispiel vorangehen. Kurse sind in der Regel dann gut, wenn der Kursleiter den Mut zu Lücke hat, und der Schüler mitdenken muss, dadurch auch Erfolgserlebnisse hat. Warum nicht import this oder import antigravity als wieder mal ein so cobol mässiges Hallo Welt. Da kann man dann auch das Modularkonzept ansprechen und das im Laufe des Kurses neue Module geschrieben werden. Die aktuellen Python Versionen nehmen. Python 2.7.3 -> 2.7.13 Python 3.2.3 -> 3.6.3 ich würde eher auf die allgemeinen Python Docs verweisen: https://docs.python.org, https://www.python.org/ Unter windows würde ich eher empfehlen miniconda oder anaconda zu installieren, sonst wirds schnell komplizierter, wenn derjenige mal was machen möchte. Morphologische Diagramme, würde ich in den Appendix tun. Wenn ich mir Überlege wieviel Zeit das kostet und der Schüler nichts zu tun hat während man die immer wieder erklärt, wird man meiner Meinung nach leicht langweilend. Bei den Operatoren, könnte man ein Taschenrechner Beispiel nehmen, der Leser fragt sich in der Regel warum oder für was er das denn braucht. Wo ist denn import erklärt, from sehe ich? lambda gehört zu den Advanced Kenntnissen, das würde ich nicht so früh bringen. help() fehlt an der Stelle. In meinen Augen fehlt insgesamt das "machen". Python ist ein interpreter, durch ausprobieren kann vieles verinnerlicht werden. Was ist das Ziel des Kurses, der rote Faden, entsteht am Ende etwas? Ich empfinde in Bezug auf das "machen" den Kurs zu umfangreich. Es ist eher ein Nachschlagewerk. Grüße Reimar On Mon, Oct 16, 2017 at 2:22 PM, Stefan Ram <ram(a)zedat.fu-berlin.de> wrote: > Ein erster Entwurf meines Python-Kurses: > > http://www.purl.org/stefan_ram/pub/python-kurs > > . (Bei 403 mit Google-Referrer auf die Seite gehen.) > > _______________________________________________ > python-de maillist - python-de(a)python.org > https://mail.python.org/mailman/listinfo/python-de >

1 0