Mailman 3 February 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

Re: [Python-de] Keywords wie Autor, Version, Erstelldatum im Quelltext(melinkat)
by Peter J. Holzer 27 Feb '18

27 Feb '18

On 2018-02-26 17:25, Klaus Melinkat <klaus(a)melinkat.de> wrote: > Ich hatte schon damit gerechnet, dass GIT es nicht hergibt und es auch > nicht gewollt ist. > > Schade, ich habe bei mir noch Quellcode (Fortran) aus 1975 gefunden. Da > Stand noch sehr viel Beschreibung im Kopf der Source und ich konnte was > damit anfangen. Git hindert Dich nicht daran, selbst eine Beschreibung in der Source zu schreiben (was Du 1975 sicherlich auch gemacht hast). hp -- _ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung: |_|_) | | Man feilt solange an seinen Text um, bis | | | hjp(a)hjp.at | die Satzbestandteile des Satzes nicht mehr __/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel

1 0

Re: [Python-de] Keywords wie Autor, Version, Erstelldatum im Quelltext(melinkat)
by Klaus Melinkat 26 Feb '18

26 Feb '18

Ich hatte schon damit gerechnet, dass GIT es nicht hergibt und es auch nicht gewollt ist. Schade, ich habe bei mir noch Quellcode (Fortran) aus 1975 gefunden. Da Stand noch sehr viel Beschreibung im Kopf der Source und ich konnte was damit anfangen. Manchmal lebt Software doch länger als man denkt! Vielen Dank für die Antworten! Klaus Melinkat > On 2018-02-25 10:26, Klaus Melinkat <klaus(a)melinkat.de> wrote: > > Hallo, > > > > ich habe nach 20 Jahren wieder mit dem Programmieren angefangen. > > In meinen alten Quellcodes (zum Teil aus 1985) stehen ne Menge > > Keywords aus SVN oder RCS, so dass ich Version usw. lesen konnte. > > In meinen auch. > > > WIe arbeitet Ihr in GIT. Wie kann ich sicherstellen, dass die oben > > genannten Infos auch in Zukunft (ohne GIT) lesbar sind? Oder denke ich > > falsch? > > Das ist in git prinzipiell nicht vorgesehen. Es ist auch bei RCS/CVS oder SVN > eher nur in Spezialfällen sinnvoll. > > Wenn Du die Versionsnummer irgendwo in den Sourcen stehen haben > möchtest, verwendest Du am besten "git describe". Das erzeugt Output wie > den folgenden: > > p2018.02.15-1-ga8a7161 > > p2018.02.15 ist hier das letzte Tag, das ich vergeben habe (Preview-Version > vom 15. Februar 2018), seitdem gab es 1 ungetaggte Änderung, und die > Revision beginnt mit a8a7161. > > Sinnvollerweise schreibt man das aber nicht in ein File, das man eincheckt > (denn damit hätte man es geändert, und müsste es einchecken, wodurch > sich der Hash ändert, etc.), sondern in irgendwas, was man vollständig > automatisch erzeugt. Das Datum kann man dort auch gleich unterbringen > (und vielleicht zwischen Datum der Version und Build-Datum unterscheiden). > > Den Autorennamen würde ich gar nicht vom VCS erzeugen lassen: Denn das > fügt dann üblicherweise den Namen der Person ein, die die letzte Änderung > vorgenommen hat, und das ist nicht unbedingt diejenige, die man als Autor > bezeichnen würde. > > hp > > > -- > _ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung: > |_|_) | | Man feilt solange an seinen Text um, bis > | | | hjp(a)hjp.at | die Satzbestandteile des Satzes nicht mehr > __/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel >

1 0

Re: [Python-de] Keywords wie Autor, Version, Erstelldatum im Quelltext mit GIT
by Peter J. Holzer 26 Feb '18

26 Feb '18

On 2018-02-25 10:26, Klaus Melinkat <klaus(a)melinkat.de> wrote: > Hallo, > > ich habe nach 20 Jahren wieder mit dem Programmieren angefangen. > In meinen alten Quellcodes (zum Teil aus 1985) stehen ne Menge > Keywords aus SVN oder RCS, so dass ich Version usw. lesen konnte. In meinen auch. > WIe arbeitet Ihr in GIT. Wie kann ich sicherstellen, dass die oben > genannten Infos auch in Zukunft (ohne GIT) lesbar sind? Oder denke ich > falsch? Das ist in git prinzipiell nicht vorgesehen. Es ist auch bei RCS/CVS oder SVN eher nur in Spezialfällen sinnvoll. Wenn Du die Versionsnummer irgendwo in den Sourcen stehen haben möchtest, verwendest Du am besten "git describe". Das erzeugt Output wie den folgenden: p2018.02.15-1-ga8a7161 p2018.02.15 ist hier das letzte Tag, das ich vergeben habe (Preview-Version vom 15. Februar 2018), seitdem gab es 1 ungetaggte Änderung, und die Revision beginnt mit a8a7161. Sinnvollerweise schreibt man das aber nicht in ein File, das man eincheckt (denn damit hätte man es geändert, und müsste es einchecken, wodurch sich der Hash ändert, etc.), sondern in irgendwas, was man vollständig automatisch erzeugt. Das Datum kann man dort auch gleich unterbringen (und vielleicht zwischen Datum der Version und Build-Datum unterscheiden). Den Autorennamen würde ich gar nicht vom VCS erzeugen lassen: Denn das fügt dann üblicherweise den Namen der Person ein, die die letzte Änderung vorgenommen hat, und das ist nicht unbedingt diejenige, die man als Autor bezeichnen würde. hp -- _ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung: |_|_) | | Man feilt solange an seinen Text um, bis | | | hjp(a)hjp.at | die Satzbestandteile des Satzes nicht mehr __/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel

1 0

Keywords wie Autor, Version, Erstelldatum im Quelltext mit GIT
by Klaus Melinkat 25 Feb '18

25 Feb '18

Hallo, ich habe nach 20 Jahren wieder mit dem Programmieren angefangen. In meinen alten Quellcodes (zum Teil aus 1985) stehen ne Menge Keywords aus SVN oder RCS, so dass ich Version usw. lesen konnte. WIe arbeitet Ihr in GIT. Wie kann ich sicherstellen, dass die oben genannten Infos auch in Zukunft (ohne GIT) lesbar sind? Oder denke ich falsch? Grüße Klaus Melinkat

2 1

inspection bis nach oben
by Reimar Bauer 24 Feb '18

24 Feb '18

Hallo Zusammen Ich hab ein Tool das sich merkt was in einer Oberfläche eingestellt wurde und beim nächsten Start das genauso wieder einstellt. Nun kann dieses Tool von verschiedenen anderen Programmen aufgerufen werden. Da macht es dann Sinn, dass ich in Abhängigkeit des aufrufendem Programms das Setup speichern/wiederherstellen kann. Ich hab schon ein wenig gesucht und den Ansatz gefunden. https://gist.github.com/techtonik/2151727 Das macht schonmal was. ich brauche aber den initialen Module Namen so gesehen, das aller oberste was alles andere Bibliotheken dann aufruft. Habt ihr ne Idee wie man da dran kommt? Viele Grüße Reimar

2 1

ANN: Aufruf zur Beteiligung am Augsburger Linux-Infotag 2018 (Einreichfrist 25. Februar)
by Ingo Blechschmidt 19 Feb '18

19 Feb '18

Liebe Python-Enthusiastinnen und -Enthusiasten, vielleicht hat jemand von euch Lust, den Augsburger Linux-Infotag 2018 durch einen Vortrag, Workshop, Lightning Talk oder Stand zu bereichern. Wir freuen uns sowohl über Python-bezogene Beiträge (es wurden schon IPython und Django vorgestellt) als auch über Beiträge, die andere Programmiersprachen thematisieren (es waren schon Ruby, Erlang, Haskell und JavaScript vertreten) oder gar nichts mit Programmieren zu tun haben. Details: https://www.luga.de/Aktionen/LIT-2018/ Wer sich nicht sicher ist, ob eine Vortragsidee zum Linux-Infotag passt, kann einfach nachfragen. Viele Grüße Ingo

1 0

Python3 - pathlib - python-gnupg Problem
by Maurice Kemmann 06 Feb '18

06 Feb '18

Hallo, ich nutze pathlib um OS unabhängige Scripte zu schreiben. Im Moment spiele ich ein wenig mit python-gnupg herrum und laufe in folgendes Problem: <code> import gnupg from pathlib import Path from pprint import pprint gpg = gnupg.GPG(gnupghome=Path("/home/mucki/.gnupg/")) <\code> Das führt zu folgenden Fehler unter Linux: >> python3 gpg-test.py Traceback (most recent call last): File "gpg-test.py", line 5, in <module> gpg = gnupg.GPG(gnupghome=Path("/home/mucki/.gnupg/")) File "/usr/local/lib/python3.6/site-packages/gnupg.py", line 755, in __init__ p = self._open_subprocess(["--version"]) File "/usr/local/lib/python3.6/site-packages/gnupg.py", line 832, in _open_subprocess logger.debug("%s: %s", result.pid, debug_print(cmd)) File "/usr/lib64/python3.6/subprocess.py", line 461, in list2cmdline needquote = (" " in arg) or ("\t" in arg) or not arg TypeError: argument of type 'PosixPath' is not iterable Unter Windows 10 gibt es eine passende Fehlermeldung mit "type WindowsPath not iterable". Es scheint ja mit dem subprocess module zusammenzuhängen, aber hier hört mein Wissen leider auf. Kann mir jemand helfen? Liegt der Fehler bei mir? Wenn ja, warum? Danke, Maurice

3 4