Mailman 3 October 2018 - 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

Probleme bei der initalisierung
by Maximilian Huber 10 Nov '18

10 Nov '18

Hallo Leute, ich versuche python 3.7 in mein c++ programm einzubinden. ich habe python mit visual studio 2017 compiliert und es scheint ein paar fehler zu haben aber die .lib und .dll dateien wurden erfolgreich erstellt. jetzt versuche ich das anfangsbeispiel zu compilieren und es funktioniert, das problem ist ich bekomme immer die folgende fehlermeldung: Fatal Python error: initfsencoding: unable to load the file system codec ModuleNotFoundError: No module named 'encodings' Current thread 0x000011b8 (most recent call first): ich hoffe jemand hier kann mir weiterhelfen... noch einen schoenen tag und alles gute!

5 14

Visual Studio Code
by Marco Bakera 05 Nov '18

05 Nov '18

Hallo zusammen! Ich nutze seit einiger Zeit Sublime Text 3 für die Entwicklung kleiner und Pycharm für größere Projekte. Hat jemand von euch Erfahrung mit Visual Studio Code gesammelt und kann sagen, wie es sich gegenüber Sublime und Pycharm verhält? Danke. Gruß, der Marco.

5 5

name2type mapping
by Thomas Güttler 29 Oct '18

29 Oct '18

Hallo, ich habe mal eine Idee veröffentlicht, die mir schon lange vorschwebt: https://github.com/guettli/python-name2type-mapping/ Feedback is willkommen. ------------------------------ Python name2type mapping In October 2018 on the mailing list python-ideas some developers encouraged me, that the idea of a name2type mapping would be usefull. Goal: Better type-hints in IDEs. This is not the goal: Type-hints which get used during run-time. Syntax Proposal The name2type mapping is defined in the docstring of a Python file. The general syntax is "name2type:" followed by a comma sperated list of variable names. Then ":", then the type hint. Examples: """ name2type: my_int, my_number, ....: int name2type: request*: django.http.HttpRequest """" If the docstring is in a file called __init__.py, then the type hints get specified for all files below this directory (recursively). Misc The name2type mapping is just a fall-back. First the IDE does the usual type detection and if no type could be found, then name2type mapping gets used. Except explicitly switched off. But this switch is not part of the spec. -- Thomas Guettler http://www.thomas-guettler.de/ I am looking for feedback: https://github.com/guettli/programming-guidelines

3 5

Probleme bei der initalisierung
by Maximilian Huber 29 Oct '18

29 Oct '18

Hallo Leute, ich versuche python 3.7 in mein c++ programm einzubinden. ich habe python mit visual studio 2017 compiliert und es scheint ein paar fehler zu haben aber die .lib und .dll dateien wurden erfolgreich erstellt. jetzt versuche ich das anfangsbeispiel zu compilieren und es funktioniert, das problem ist ich bekomme immer die folgende fehlermeldung: Fatal Python error: initfsencoding: unable to load the file system codec ModuleNotFoundError: No module named 'encodings' Current thread 0x000011b8 (most recent call first): ich hoffe jemand hier kann mir weiterhelfen... noch einen schoenen tag und alles gute!

2 1

Re: [Python-de] Gehoertraining mit geringen Python-Kenntnissen
by Christopher Arndt 20 Oct '18

20 Oct '18

Am 20.10.18 um 14:46 schrieb Stefan Ram: > eingabe = input( "War dies eine Quinte (q) oder eine grosse Terz (t)? " ) > print( 'Es war', intervall * 'eine Quinte.' +( 1 - intervall )* 'eine Terz.' ) > richtige_antwort = intervall * 'q' +( 1 - intervall )* 't' > bewertung = isclose( 0, ord( eingabe )- ord( richtige_antwort )) > print\ > ( 'Ihre Antwort war', bewertung * 'richtig.' +( 1 - bewertung )* 'falsch.' ) Danke für die Erheiterung des Tages! interval = bewertung = 1 print('Es war', interval * 'eine Finte.' + (1 - interval) * 'ein Scherz.') print('Ihr Beispiel war', bewertung * 'richtig' + (1 * bewertung) * ' krank.') Chris

1 0

Re: [Python-de] Gehoertraining mit geringen Python-Kenntnissen
by Peter Otten 20 Oct '18

20 Oct '18

Am Sa Oktober 20 2018, 12:46:47 schrieb Stefan Ram: > Gerade habe ich zu meinem Kurs das folgende Programm zum > Gehörtraining als Programmbeispiel hinzugefügt. > > Man beachte, wie darin Dinge, die man normalerweise mit Hilfe > von Vergleichsoperatoren und Kontrollstrukturen ausdrücken > würde, ohne Vergleichsoperatoren und Kontrollstrukturen > formuliert werden, da Vergleichsoperatoren und > Kontrollstrukturen an der Stelle des Kurses, an der dieses > Skript vorgestellt werden soll, noch nicht behandelt wurden. > Grundrechenarten (einschließlich »+« und »*« für Strings), > Funktionsaufrufe (sowie auch Kommentare, Namen, Zuweisungen > und from-Importe) wurden hingegen schon behandelt ... > > from winsound import Beep > from random import random > from math import isclose Zu früh für Vergleichsoperatoren, aber dann isclose() aus dem Hut zaubern... > quinte = 2/3 > grosse_terz = 4/5 > > erste_frequenz_in_Hz = int( random() * 1000 + 110 ) > intervall = int( random() * 2 ) # 1 = Quinte, 0 = grosse Terz > frequenzverhaeltnis = intervall * quinte +( 1 - intervall )* grosse_terz > zweite_frequenz_in_Hz = int( erste_frequenz_in_Hz * frequenzverhaeltnis ) > > dauer_in_millisekunden = 400 > Beep( erste_frequenz_in_Hz, dauer_in_millisekunden ) > Beep( zweite_frequenz_in_Hz, dauer_in_millisekunden ) > > eingabe = input( "War dies eine Quinte (q) oder eine grosse Terz (t)? " ) > print( 'Es war', intervall * 'eine Quinte.' +( 1 - intervall )* 'eine Terz.' > ) richtige_antwort = intervall * 'q' +( 1 - intervall )* 't' > bewertung = isclose( 0, ord( eingabe )- ord( richtige_antwort )) > print\ > ( 'Ihre Antwort war', bewertung * 'richtig.' +( 1 - bewertung )* 'falsch.' ) Wäre doch gelacht, wenn du deine Studenten nicht schon mit der ersten Lektion zur Verzweiflung bringst ;)

1 0

Re: [Python-de] einheitliches Vorgehen beim Öffnen von Dateien.
by Hermann Riemann 20 Oct '18

20 Oct '18

Am 18.10.2018 um 09:59 schrieb Thomas Güttler: > Wenn man gemeinsam Quelltext schreibt, ist es sinnvoll sich Guidelines > zu erstellen. > Was haltet ihr von diesen Guidelines? Teils ,teils. Ich rücke gerne 3 statt 4 Zeichen ein. Ich sehe da bei gemeinsamer Verwendung keine ernsthafte Probleme, weil man die Dateien leicht mit einem Python Programm line=( (len(line)-line(line.lstrip()) *4//3)*' '+line.lstrip() umbauen kann. > Ziel: einheitliches Vorgehen beim Öffnen von Dateien. > So lange wir Python2 unterstützen soll io.open() verwendet werden. Wenn ich cgi verwende, verwende ich codecs.open Ansonsten wegen der besseren Lesbarkeit einfach open. > Es sollte immer der Mode angegeben werden: also meist eines aus dieser > Liste: 'rt', 'rb', 'wt', 'wb' Als mode verwende ich nichts (default ist 'r') oder "w". Hermann der bisher with nicht verwendet hat. -- http://www.hermann-riemann.de

1 0

Re: [Python-de] einheitliches Vorgehen beim Öffnen von Dateien.
by Stefan Schwarzer 19 Oct '18

19 Oct '18

On 19/10/2018 17.46, Stefan Ram wrote: > Stefan Schwarzer <sschwarzer(a)sschwarzer.net> writes: >> On 18/10/2018 09.59, Thomas Güttler wrote: >> Leider werden `f` und `file` mitunter sowohl für >> Dateinamen (manchmal auch Pfade) als auch für >> Dateiobjekte verwendet. > > Hier wird oft empfohlen, kurze Namen für kleine > Gültigkeitsbereiche und lange Namen für große > Gültigkeitsbereiche zu verwenden. Ich verstehe es eher so, dass kleine Gültigkeitsbereiche kurze Namen _eher rechtfertigen_ als große Gültigkeitsbereiche. Wenn es dem Verständnis hilft, nutze ich meist auch für kleinere Gültigkeitsbereiche längere Namen. >> Lieber ein langer `with`-Block als keine sauber >> geschlossenen Dateien. ;-) > > Und wie würde das von mir angesprochene Refaktorieren im > Falle eines langen with-Blocks aussehen? Man würde ihn > normalerweise in (mindestens) eine separate Funktion auslagern. Das Auslagern des `with`-Blocks in eine Funktion oder Methode ist die naheliegendste Option, aber ich denke, man sollte das nicht sofort "instinktiv" machen, sondern auch gründlich über andere Optionen nachdenken. Spontan fallen mir ein: - Nur einen Teil des Blocks extrahieren, so dass er ein in sich schlüssiges Konzept enthält. Das macht die neue Funktion/Methode nicht nur einfacher zu verwenden, sondern erhöht auch die Wahrscheinlichkeit, dass man sie auch noch woanders sinnvoll verwenden kann. - Teile aus dem `with`-Block vor den Block ziehen. - Code kompakter schreiben (aber damit würde ich besonders vorsichtig sein). Was jeweils passt (ggf. in Kombination) muss man im Einzelfall prüfen/abwägen. Viele Grüße Stefan

1 0

einheitliches Vorgehen beim Öffnen von Dateien.
by Thomas Güttler 18 Oct '18

18 Oct '18

Wenn man gemeinsam Quelltext schreibt, ist es sinnvoll sich Guidelines zu erstellen. Was haltet ihr von diesen Guidelines? Ziel: einheitliches Vorgehen beim Öffnen von Dateien. So lange wir Python2 unterstützen soll io.open() verwendet werden. Es sollte immer der Mode angegeben werden: also meist eines aus dieser Liste: 'rt', 'rb', 'wt', 'wb' Wenn im Textmode geöffnet wird, braucht nicht 'utf8' angegeben werden, denn das ist der Default (locale.getpreferredencoding(False) ist bei uns immer 'utf8') Wenn man nur den Inhalt braucht, dann ist diese einfache Variante zulässig (ohne with-Statement) content = io.open(my_file, 'rt').read() Auch beim Schreiben? Die Variable wird „f“ genannt: with io.open(my_file, 'wt') as f: f.write(...) So wird das meist in der Python-Doku gemacht: Bsp: Methods of File Objects Der with-Block nach dem Open sollte kurz sein. Also nicht länger etwa 6 Zeilen. Gruß, Thomas -- Thomas Guettler http://www.thomas-guettler.de/ I am looking for feedback: https://github.com/guettli/programming-guidelines

5 4