Mailman 3 December 2014 - 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

Re: [Python-de] utf8
by Hermann Riemann 30 Dec '14

30 Dec '14

Andreas Jung schrieb: >> #!/usr/bin/python3 >> # -*- coding: utf-8 -*- >> import codecs >> >> .. >> f=codecs.open(dateiname,'r',"utf8") >> .. >> >> >> Ist die Zeile mit coding noch aktuell? > Ja, aber die Coding Präambel hat absolut nichts mit dem 'encoding' > Parameter von open() zu tun. Die coding Zeile mußte ich, meiner Erinnerung nach, noch in Python2.6 oder 2.7 einfügen wenn ich in der *.py Datei Sonderzeichen verwendete. Es diente dem Phyton interpreter beim Quelltext lesen. Und ich hoffte, das es bei Python3 nicht mehr notwendig sei. In https://docs.python.org/3/howto/unicode.html steht: The default encoding for Python source code is UTF-8 Danach könnte ich bei Python3 die Zeile weglassen. Die (mit vi erzeugte) Datei, die ä='ö' print(ä) enthält, läßt sich mit python3 ausführen Ich vermute, es gibt jetzt folgende Fälle, ich lasse das coding weg, und wenn sich im System oder in Python das mit utf8 ändert bekomme ich Probleme, oder ich behalte eine coding Form, und vergesse bei einer globalen Änderung des utf8 Formats aller Textdateien diese coding Zeilen. (Ich vermute, dass ich für den Rest meines Lebens bei utf8 bleibe. ) Das mit dem codecs habe ich irgendwo gelesen, und es hat bei Dateien mit utf-Zeichen funktioniert. Im Gegensatz zu f=open(dateiname,'r') wie es in diversen Bücher beschrieben ist. Was ich machen werde, wenn ich nicht weis, ob es utf8 oder ISO irgendwas ist, ( *.csv) weis ich noch nicht. Vermutlich es mit mit try versuchen und bei exception die mit os.system(iconv oder recode ..) umcodierte Datei nochmal einlesen. Hermann der vielleicht Zeilen mit coding: aus *.py entfernt -- http://www.Hermann-Riemann.de

4 3

Re: [Python-de] utf8
by Hermann Riemann 30 Dec '14

30 Dec '14

Stefan Schwarzer schrieb: > On 2014-12-28 09:32, Hermann Riemann wrote: > [Encoding in Quelltexten] >> Meine aktuellen Dateien.py sehen etwas so aus: >> >> #!/usr/bin/python3 >> # -*- coding: utf-8 -*- > > # coding: utf-8 > > reicht übrigens auch, siehe > https://www.python.org/dev/peps/pep-0263/ . Und da steht etwas von Abhängigkeit vom Editor. Da ich aber mehrere Editoren verwende (meist emacs, manchmal vi, xemacs und vielleicht auch mal andere) mag ich mich da nicht festlegen. > In Python 2 ist ASCII das Standard-Encoding für > Quelltext-Dateien, in Python 3 ist es UTF-8. In strings gingen vielleicht auch ISO-Zeichen (>127). > [Encoding von Daten während der Laufzeit] >> import codecs >> .. >> f=codecs.open(dateiname,'r',"utf8") >> .. > > Ich würde die Funktion `open` aus dem `io`-Modul nehmen: > > import io > > fobj = io.open(dateiname, "r", encoding="utf8") fobj =codecs.open(dateiname, "r", "utf8") ist kürzer > > beziehungsweise > > with io.open(dateiname, "r", encoding="utf8") as fobj: > ... > > Achtung: So geöffnete Dateien arbeiten nur mit > Unicode-Strings, was ich aber normalerweise für eine gute > Sache halte. Details siehe > https://docs.python.org/2.7/library/io.html#io.open > > `io.open` gibt es ab Python 2.6, also auch in Python 3. Die Datei mit dem Inhalt: import locale print(locale.getpreferredencoding()) liefert nach Aufruf mit Phyton3 UTF-8 Wenn also The default encoding is platform dependent (whatever locale.getpreferredencoding() returns) gilt müsste encoding default UTF-8 sein und nicht None wie bei der gelb markierten Parameterliste Wenn ich dem codecs Hinweis nachgehe lese ich in https://docs.python.org/2.7/library/codecs.html#module-codecs etwas von codecs.BOM_UTF8 > `io.open` ist identisch mit der eingebauten `open`-Funktion > in Python 3. D.h. ich könnte normale open ohne Parameter für encoding für utf8-Dateien in Python>=3 benutzen. Mit open ging mal bei utf-8 etwas schief, was mich zur Suche nach Alternativen veranlasste. Zu einigen Parameter habe ich noch fragen. ( Früher habe ich Dateien meist mit C bearbeitet.) buffering: Wird bei buffering=0 der Wert sofort herausgeschrieben, so dass bei Programmabbruch man das bis dahin geschriebene lesen kann? Als Ersatz für flush() newline: Das Programm f=open('x','w') f.write("bla\nbla") f.close() f=open('x') for line in f:print(len(line)) liefert: 4 3 passt vielleicht nicht zur Beschreibung >> Hermann >> der in jeder von ihm verwendete Programmiersprache >> utf-8 Problem hatte oder hat. > > Welche Art von Problem(en)? Z.B. QT4 utf im Menutext aus unterschiedlichen Quellen In Python mit diakritischen Zeichen (Im mit Python programmiertem Editor eine Stelle im Fenster für mehrere "Buchstaben" im string) oder im anderen Fall bei gewissen Werten erhalte ich beim Schreiben: UnicodeEncodeError -- http://www.Hermann-Riemann.de

2 1

utf8
by Hermann Riemann 28 Dec '14

28 Dec '14

Meine aktuellen Dateien.py sehen etwas so aus: #!/usr/bin/python3 # -*- coding: utf-8 -*- import codecs .. f=codecs.open(dateiname,'r',"utf8") .. Ist die Zeile mit coding noch aktuell? Wenn ich Text editiere, verwende ich utf-8 Hermann der in jeder von ihm verwendete Programmiersprache utf-8 Problem hatte oder hat. -- http://www.Hermann-Riemann.de

4 4

Re: [Python-de] Debug-Ausgabe
by Thomas 'PointedEars' Lahn 21 Dec '14

21 Dec '14

Stefan Schwarzer wrote: > On 2014-12-21 11:44, Thomas 'PointedEars' Lahn wrote: >> Stefan Schwarzer wrote: >>> […] Thomas 'PointedEars' Lahn wrote: >>>> [X-Post & F'up2 de.comp.lang.python] >>>>> Du schriebst am Wed, 17 Dec 2014 13:17:19 +0100: >>>> Lies und beherzige bitte <http://einklich.net/usenet/zitier>. >>> Auf welchen der Punkte dort beziehst du dich in diesem >>> Kontext? :) >> Du möchtest Dich nicht dummstellen, vertrau mir. > > Die Frage war ernst gemeint. Die Antwort auch. Oder bist Du mit dem Vergleich tatsächlich überfordert? >>>>>>> Ist es und tut es aber. Ich benutze z.B. gerne für "transiente" >>>>>>> Ausgaben (für Tests und zum Prüfen) vollständig ausgerückte >>>>>>> Ausgabe-Statements (die also ab Spalte 1 stehen). Das fällt bei >>>>>>> einem einigermaßen >>>>> ... >>>>>>> _Geht_ in Python _nicht_. >>>>>> >>>>>> debug = True >>>>>> >>>>>> if debug: >>>>>> statement1 >>>>>> statement2 >>> >>> Also, das geht in Python schon >> >> Es ging hier darum, „mal eben“ Debug-Anweisungen einzufügen. Das geht in >> Python tatsächlich auf diese Weise nicht, weil die Einrückung eine Rolle >> spielt. Die Anweisungen beginnen daher nicht notwendigerweise in Spalte >> 1. > > Aber der Ansatz lässt sich doch auf beliebige Einrückungen > übertragen? Noch einmal zur Klarstellung der (nicht von mir aufgestellten) Behauptung: In Python ist debug = True for …: blubb if debug: pass bla syntaktisch etwas anderes als debug = True for …: blubb if debug: pass bla In Sprachen, bei denen die Einrückung keine syntaktische Rolle spielt, ist das nicht so. Ein zu letzterem äquivalentes Beispiel in ECMAScript (in Ed. 1 bis 3 und 5.x ebenfalls eine Sprache mit ausschliesslich dynamischer Typüberprüfung): var debug = true; for (…) { blubb; if (debug) { ; } bla; } Dies wurde als Nachteil von Python gegenüber anderen Sprachen dargestellt. Ich habe argumentiert, dass solcher Code von vornherein nicht geschrieben werden sollte, und sich bei alternativem Ansatz keine sprachspezifischen Nachteile ergeben. >>> meintest du wahrscheinlich >>> >>> if kwargs.pop('min_level', None) is None: >> >> Nein, ich meinte was ich schrieb. > > Wenn du `**kwargs` benutzt und an ein Keyword-Argument > willst, musst du auf einen Key zugreifen, nicht auf ein > Attribut: […] Stimmt, danke. Da war ich wohl noch zu sehr in Gedanken bei meiner Klasse, die diese Funktion benutzt. Gemeint war “kwargs.get('min_level', None)”, wobei ich gerade gelernt habe, dass ich None in dem Fall nicht angeben muss: | >>> print(({}).get.__doc__) | D.get(k[,d]) -> D[k] if k in D, else d. d defaults to None. >>> An sich würde ich aber gar nicht `kwargs` modifizieren, >>> sondern den Wert herausziehen: >>> >>> min_level = kwargs.pop('min_level', 1) >> >> Das modifiziert `kwargs' ebenfalls: >> >> | >>> print(({}).pop.__doc__) >> | D.pop(k[,d]) -> v, remove specified key and return the corresponding >> | value. If key is not found, d is returned if given, otherwise KeyError >> | is raised >> | >>> > > Klar, was aber in dem Fall beabsichtigt war. :-) Weshalb behauptetest Du, `kwargs' werde nicht modifiziert, obwohl es das offensichtlich auch mit dem von Dir vorgeschlagenen Ansatz wird? -- PointedEars Twitter: @PointedEars2 Please do not cc me. / Bitte keine Kopien per E-Mail.

2 1

Re: [Python-de] Debug-Ausgabe
by Thomas 'PointedEars' Lahn 21 Dec '14

21 Dec '14

Stefan Schwarzer wrote: > On 2014-12-21 12:37, Stefan Schwarzer wrote: >>>> An sich würde ich aber gar nicht `kwargs` modifizieren, >>>> sondern den Wert herausziehen: >>>> >>>> min_level = kwargs.pop('min_level', 1) >>> >>> Das modifiziert `kwargs' ebenfalls: >>> [...] > > sorry, hier habe ich mir in der Tat selbst widersprochen. > > Als ich das schrieb, hatte ich im Sinn, `min_level` als > Keyword-Argument mit Default zu verwenden und gar nicht in > `kwargs` unterzubringen, aber das geht in Kombination mit > `**kwargs` gerade nicht. Die Funktion sieht jetzt so aus: def dmsg (*args, **kwargs): if not kwargs.get('file'): kwargs['file'] = stderr min_level = kwargs.pop('min_level', 1) if debug_level >= min_level: print(*args, **kwargs) Soweit ich sehe, funktioniert das, dass heisst man kann überall dort print(…) durch dmsg(…) ersetzen, wo man auf stderr schreiben und dies abhängig vom Debug-Level machen will. Bei weiterer Recherche könnte ich wohl auch <https://docs.python.org/3/library/logging.html> entsprechend zurechtbiegen, statt aus Obigem meine eigene Logging-Klasse zu bauen. Zwischen logging.NOTSET (0) und logging.DEBUG (10) sowie zwischen logging.DEBUG und logging.INFO (20) wären ja noch Werte frei. Was meint ihr? -- PointedEars Twitter: @PointedEars2 Please do not cc me. / Bitte keine Kopien per E-Mail.

1 0

Chemnitzer Linux-Tage 2015
by Thomas Güttler 21 Dec '14

21 Dec '14

Hallo, die Anmeldung für Vorträge für die Chemnitzer Linux-Tage ist noch bis zum 07.01 möglich. Wird es wieder einen Stand des Python Verbandes geben? Möchte jemand einen Einsteiger Workshop halten? Falls nicht könnte ich das machen. Einen Vortrag über PyCharm habe ich gerade eingereicht. Gruß, Thomas Siehe: https://chemnitzer.linux-tage.de/2015/de -- http://www.thomas-guettler.de/

5 10

Re: [Python-de] Debug-Ausgabe
by Thomas 'PointedEars' Lahn 21 Dec '14

21 Dec '14

Stefan Schwarzer wrote: > On 2014-12-21 12:37, Stefan Schwarzer wrote: >>>> An sich würde ich aber gar nicht `kwargs` modifizieren, >>>> sondern den Wert herausziehen: >>>> >>>> min_level = kwargs.pop('min_level', 1) >>> >>> Das modifiziert `kwargs' ebenfalls: >>> [...] > > sorry, hier habe ich mir in der Tat selbst widersprochen. > > Als ich das schrieb, hatte ich im Sinn, `min_level` als > Keyword-Argument mit Default zu verwenden und gar nicht in > `kwargs` unterzubringen, aber das geht in Kombination mit > `**kwargs` gerade nicht. ACK. Ich fand es in der Tat befremdlich, dass sich print() an Argumenten stört, die es nicht benutzt; sonst hätte ich **kwargs unmodifiziert an print() weiterreichen können: | $ python3 | Python 3.4.2 (default, Dec 2 2014, 15:08:18) | [GCC 4.9.2] on linux | Type "help", "copyright", "credits" or "license" for more information. | >>> print("foo", min_level=1) | Traceback (most recent call last): | File "<stdin>", line 1, in <module> | TypeError: 'min_level' is an invalid keyword argument for this function -- PointedEars Twitter: @PointedEars2 Please do not cc me. / Bitte keine Kopien per E-Mail.

1 0

Re: [Python-de] Debug-Ausgabe
by Thomas 'PointedEars' Lahn 21 Dec '14

21 Dec '14

Stefan Schwarzer wrote: > […] Thomas 'PointedEars' Lahn wrote: >> [X-Post & F'up2 de.comp.lang.python] > > Mir fehlt in diesem Posting relativ viel vom Kontext, > deshalb kann es sein, dass ich auf Sachen eingehe, die schon > erledigt sind. Ich habe so vollständig wie technisch möglich zitiert. Den übrigen Kontext kannst Du den Referenzen (“References”-Headerfeld) entnehmen. Dies zu tun, ist bei einem Crosspost (X-Post) ratsam. >>> Du schriebst am Wed, 17 Dec 2014 13:17:19 +0100: >> Lies und beherzige bitte <http://einklich.net/usenet/zitier>. > > Auf welchen der Punkte dort beziehst du dich in diesem > Kontext? :) Du möchtest Dich nicht dummstellen, vertrau mir. >>>>> Ist es und tut es aber. Ich benutze z.B. gerne für "transiente" >>>>> Ausgaben (für Tests und zum Prüfen) vollständig ausgerückte >>>>> Ausgabe-Statements (die also ab Spalte 1 stehen). Das fällt bei einem >>>>> einigermaßen >>> ... >>>>> _Geht_ in Python _nicht_. >>>> >>>> debug = True >>>> >>>> if debug: >>>> statement1 >>>> statement2 > > Also, das geht in Python schon Es ging hier darum, „mal eben“ Debug-Anweisungen einzufügen. Das geht in Python tatsächlich auf diese Weise nicht, weil die Einrückung eine Rolle spielt. Die Anweisungen beginnen daher nicht notwendigerweise in Spalte 1. > und ich finde es, je nachdem, was man untersucht, auch in Ordnung. Für triviales Debugging mag das ausreichen. Sobald aber Debug-Level hinzukommen oder – das war hier der Anwendungsfall – tiefere Codeebenen berücksichtigt werden müssen, wird es unübersichtlich und schwierig wartbar. >> Diesen Ansatz empfehle ich auch für andere Programmiersprachen – >> optimal natürlich als Präprozessor-Makro. Daher stellt sich das Problem >> erst gar nicht: >> >> from sys import stderr >> >> debug_level=2 >> >> def dmsg (*args, **kwargs): >> if getattr(kwargs, 'min_level', None) is None: > > Da `kwargs` ein Mapping ist, Es ist eine dict-Instanz: ,---- | >>> def foo (*args, **kwargs): | ... print(type(kwargs)) | ... | >>> foo() | <class 'dict'> | >>> foo(bla='baz') | <class 'dict'> | >>> `---- > meintest du wahrscheinlich > > if kwargs.pop('min_level', None) is None: Nein, ich meinte was ich schrieb. >> kwargs['min_level'] = 1 > > Zusammengefasst, also inklusive des `if`, könnte man das > übrigens auch als > > kwargs.setdefault('min_level', 1) > > schreiben. :-) Ja: | >>> print(({}).setdefault.__doc__) | D.setdefault(k[,d]) -> D.get(k,d), also set D[k]=d if k not in D | >>> Danke. > An sich würde ich aber gar nicht `kwargs` modifizieren, > sondern den Wert herausziehen: > > min_level = kwargs.pop('min_level', 1) Das modifiziert `kwargs' ebenfalls: | >>> print(({}).pop.__doc__) | D.pop(k[,d]) -> v, remove specified key and return the corresponding | value. If key is not found, d is returned if given, otherwise KeyError | is raised | >>> > und dann `min_level` weiterverwenden. Dann Deshalb: > brauchst du weiter unten auch das `del` nicht. Ja, das ist eleganter. Danke. -- PointedEars Twitter: @PointedEars2 Please do not cc me. / Bitte keine Kopien per E-Mail.

3 3

Debug-Ausgabe (was: getopt: Option hat kein oder ein Argument)
by Thomas 'PointedEars' Lahn 21 Dec '14

21 Dec '14

[X-Post & F'up2 de.comp.lang.python] Sieghard Schicktanz wrote: > Hallo Bernd, > > Du schriebst am Wed, 17 Dec 2014 13:17:19 +0100: Lies und beherzige bitte <http://einklich.net/usenet/zitier>. >> > Ist es und tut es aber. Ich benutze z.B. gerne für "transiente" >> > Ausgaben (für Tests und zum Prüfen) vollständig ausgerückte >> > Ausgabe-Statements (die also ab Spalte 1 stehen). Das fällt bei einem >> > einigermaßen > ... >> > _Geht_ in Python _nicht_. >> >> debug = True >> >> if debug: >> statement1 >> statement2 > > Ok, und jetzt nochmal in einem "if" innerhalb einer dreifach > geschachtelten Schleife, bitte. > BTW, in einer Funktion, natürlich. <https://en.wikipedia.org/wiki/Moving_the_goalposts> Abgesehen davon: In Python schreibt man das IMHO nicht so, sondern geht davon aus, dass Funktionen vom Compiler inlined und unnötige Aufrufe wegoptimiert werden können. Diesen Ansatz empfehle ich auch für andere Programmiersprachen – optimal natürlich als Präprozessor-Makro. Daher stellt sich das Problem erst gar nicht: from sys import stderr debug_level=2 def dmsg (*args, **kwargs): if getattr(kwargs, 'min_level', None) is None: kwargs['min_level'] = 1 if not hasattr(kwargs, 'file'): kwargs['file'] = stderr if debug_level >= kwargs['min_level']: del kwargs['min_level'] print(*args, **kwargs) for …: for …: for …: dmsg("foo", min_level=1) Abgesehen davon: Wer in seinem Code eine dreifach verschachtelte Schleife *direkt* stehen hat, macht sehr wahrscheinlich etwas fhcsla. Denn er hat es wahrscheinlich versäumt, seinen Code mittels Subroutinen (in Python und Shell: Funktionen; in Python zusätzlich: Methoden) zu strukturieren. -- PointedEars Twitter: @PointedEars2 Please do not cc me. / Bitte keine Kopien per E-Mail.

2 1