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
Hallo,
das ist mein erstes Posting hier in der Gruppe. Keineswegs soll hier
der Versuch unternommen werden, Python schlechtzumachen, ganz im
Gegenteil. Python ist eine der besseren Programmiersprachen. Besonders
bemerkenswert ist die Eigenschaft in wenigen Zeilen Code elaborierte
Programme zu schreiben. Und wirklich langsam ist Python auch nicht,
weil es jedem frei steht, Erweiterungsbibliotheken in purem C-Code zu
schreiben und über import einzubinden.
Aber genug der Vorrede, ich möchte zum eigentlichen Thema kommen. Und zwar
habe ich mir für den Anfang ein Problem aus der Robotik herausgesucht
und zwar die Erstellung eines Rapidly-exploring random tree (RRT). Der
soll mit Hilfe von unterschiedlichen Instanzen von Box2D arbeiten um so
als Solver zu fungieren.
Eine erste Version ist bereits erstellt, keine Angst den Sourcecode gibt
es hier nicht zu sehen. Vielmehr geht es allgemein darum, wie man ein
derartiges Problem struktuiert. In der aktuellen Version wird der RRT
Tree als Klasse implementiert und die einzelnen Nodes als Array innerhalb
dieser Klasse. Leider hat das zur Folge, dass das etwas unübersichtlich
ist. Es gibt ziemlich viele Methoden und noch mehr Variablen. Erschwerend
kommt hinzu, dass man dabei sowohl in der Zeit vorwärtsgeht als auch
unterschiedliche Abzweigungen verwaltet.
Die generelle Frage die mich umtreibt ist, ob und welche
Datenstrukturen man einsetzen sollte, für derartige Probleme. Eine
Recherche bei Google hat bisher nur wenig Informationen gebracht. Es
gibt einerseits die RRT Tree Referenzimplementierung von Lavelle,
http://msl.cs.uiuc.edu/~lavalle/code.html und zum anderen einen
ausgewachsenen Motion Planner genannt OMPL. Die Lavelle Version ist zwar
schön übersichtlich, ist jedoch nicht dafür gedacht um unterschiedliche
Physik-Engine-Instanzen zu verwalten. Die OMPL Software hingegen ist
zwar leistungsfähig, setzt aber auf C++ als Programmiersprache und ist
didaktisch gesehen eine Katastrophe.
RRT Bäume sind eng verwand mit Backtracking und A* Algorithmen. Hier wird
häufig Rekursion eingesetzt die auch in Python realisierbar wäre. Aber,
Rekursion ist nicht gerade etwas, was leicht verständlich ist. Gibt es
womöglich noch etwas, was ich übersehen habe?
Hartmut Goebel wrote:
>>> > Der Doppelpunkt hat leider den Nachteil, dass er in Windows
>>> > Laufwerksbuchstaben trennt.
>> Wie wäre es mit '@'
>> Das würde einige malware, die nach email Adresse suchen, verwirren.
> "@" kommt unter OS X in Dateinamen vor.
In jedem Unix/Linux System sind alle Zeichen außer '/' und '\0'
als Zeichen in Dateinamen erlaubt.
Mit Zeichen, welche nicht zu utf-8 passen,
können Probleme bei Oberflächen wie Konsolen entstehen.
Da ist dann eher die Frage, wie häufig Zeichen vorkommen.
Hermann
der weder apple noch aktuelles windows hat.
--
www.hermann-riemann.de
Hartmut Goebel schrieb:
> für PyInstaller suchen wir momentan ein geeignetes Zeichen (möglichst
> plattformunabhängig), um "paarweise" Optionen zu trennen. Damit meine
> ich Optionen, die zwingend *zwei* Werte benötigen, z.B.
> docker run --volumne $PWD:/vagrant ...
> myprog --add-file SRC:DST ...
>
> Der Doppelpunkt hat leider den Nachteil, dass er in Windows
> Laufwerksbuchstaben trennt.
Wie wäre es mit '@'
Das würde einige malware, die nach email Adresse suchen, verwirren.
> Welches Zeichen habt Ihr in anderen Programmen gesehen?
Als Vorlage könnte die Ergänzungen in urls,
liefern, denen man Parameter und Argumente anhängt.
Da bräuchte amn weniger neues lernen.
Hermann
der ein eval auf liste statt string vermisst
welches wie das eval in lisp arbeitet
und auch das zugehörige quote
und für quote an das Ersatzzeichen @ denkt.
eval [ @+,2,3 ] was man dann nicht zu eval("2+3") umbasteln muß.
--
www.hermann-riemann.de
Am Mittwoch, 18. Mai 2016 13:18:04 UTC+1 schrieb Hartmut Goebel:
> Hallo,
>
> für PyInstaller suchen wir momentan ein geeignetes Zeichen (möglichst
> plattformunabhängig), um "paarweise" Optionen zu trennen. Damit meine
> ich Optionen, die zwingend *zwei* Werte benötigen, z.B.
>
> docker run --volumne $PWD:/vagrant ...
> myprog --add-file SRC:DST ...
>
> Der Doppelpunkt hat leider den Nachteil, dass er in Windows
> Laufwerksbuchstaben trennt.
>
> Welches Zeichen schlagt Ihr vor oder habt Ihr in anderen Programmen gesehen?
>
> --
> 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/fortbildung-iso-27001-lead-implementer
> Kolumne: http://www.cissp-gefluester.de/2010-09-mut-zur-beschraenkung
Was spricht gegen ein Leerzeichen als Trennzeichen?
mfg guenter
Am Mittwoch, 18. Mai 2016 13:18:04 UTC+1 schrieb Hartmut Goebel:
> Hallo,
>
> für PyInstaller suchen wir momentan ein geeignetes Zeichen (möglichst
> plattformunabhängig), um "paarweise" Optionen zu trennen. Damit meine
> ich Optionen, die zwingend *zwei* Werte benötigen, z.B.
>
> docker run --volumne $PWD:/vagrant ...
> myprog --add-file SRC:DST ...
>
> Der Doppelpunkt hat leider den Nachteil, dass er in Windows
> Laufwerksbuchstaben trennt.
>
> Welches Zeichen schlagt Ihr vor oder habt Ihr in anderen Programmen gesehen?
>
> --
> 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/fortbildung-iso-27001-lead-implementer
> Kolumne: http://www.cissp-gefluester.de/2010-09-mut-zur-beschraenkung
Was sorict gwgn ein Leerzeicvhe, als Trennzeichen?
mfg guenter
== Leipzig Python User Group ===
Wir treffen uns am 14. Juni um 19:00 Uhr wieder im Basislager [1].
Es gibt einen Vortrag:
Mike Müller
PyLint & Co. - Werkzeuge für besseren Code
Python hat mit PEP8_ einen offiziellen Style Guide.
Viele Open Source Projekte wenden diesen an.
Es ist äußerst empfehlenswert eigene Projekte ebenfalls PEP8-konform
zu entwickeln. Zum Glück gibt es zahlreiche Werkzeuge, die die Kontrolle der
Einhaltung der Formatierungsvorschläge von PEP8 automatisch überprüfen.
Der Vortrag stellt einige dieser Werkzeuge vor und demonstriert deren
Anwendung. Helfer wie PyLint_ können noch einiges mehr als die
Formatierung zu überprüfen. Mit statischer Quelltextanalyse weisen sie
auf potentielle Fehler und Unsauberkeiten hin. Der Vortrag gibt einen
kleinen Einblick in die zahlreichen Möglichkeiten von PyLint und
zeigt Beispiele für die Anpassung der Konfiguration an die Bedürfnisse
eigener Projekte.
Die Adresse vom Basislager ist:
Basislager Coworking
Peterssteinweg 14-16
04107 Leipzig
Raum: Mount Everest, 4. Etage
Weitere Infos:
http://www.python-academy.de/User-Group/index.html
Viele Grüße
Mike
[1] Basislager: http://basislager.co