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

QtWidgets.QFileDialog und pyfilesystem2
by Reimar Bauer 29 Sep '17

29 Sep '17

Hi Zusammen vor ein paar Tagen hab ich damit angefangen mich für das pyfilesystem2 https://www.pyfilesystem.org/ zu interessieren. Eine sehr gute Idee um diverse storages gleich zu behandeln. Andreas Jung, hat darüber schon vorgetragen https://www.slideshare.net/ajung/pyfilesystem Mir fehlt momentan ein GUI wie z.B. QtWidgets.QFileDialog in das ich diese API einhängen kann. Gibt es da bereits irgendwas? Viele Grüße Reimar

1 0

PyCon 2018 CFP is Open!
by Betsy Waliszewski 29 Sep '17

29 Sep '17

Hi, Woohoo! The PyCon 2018 CFP is open! Here is a link to all the information: https://us.pycon.org/2018/speaking/ - Tutorial proposals — deadline is 24 November 2017 AoE. - Talk, Poster, and Education Summit proposals — deadline is 3 January 2018 AoE. If you know of a company who might be interested in sponsoring, feel free to share our prospectus: https://us.pycon.org/2018/sponsors/prospectus/. Or an email intro to me would be wonderful, too. Cheers, Betsy

1 0

ANN: Python Meeting Düsseldorf - 27.09.2017
by eGenix Team: M.-A. Lemburg 26 Sep '17

26 Sep '17

________________________________________________________________________ ANKÜNDIGUNG Python Meeting Düsseldorf http://pyddf.de/ Ein Treffen von Python Enthusiasten und Interessierten in ungezwungener Atmosphäre. Mittwoch, 27.09.2017, 18:00 Uhr Raum 1, 2.OG im Bürgerhaus Stadtteilzentrum Bilk Düsseldorfer Arcaden, Bachstr. 145, 40217 Düsseldorf Diese Nachricht ist auch online verfügbar: http://www.egenix.com/company/news/Python-Meeting-Duesseldorf-2017-09-27 ________________________________________________________________________ NEUIGKEITEN * Bereits angemeldete Vorträge: Dr. Uwe Ziegenhagen "Datenanalyse mit Python pandas" Charlie Clark "Typ-Systeme in Python" Weitere Vorträge können gerne noch angemeldet werden: info(a)pyddf.de Allerdings wird vermutlich bei diesem Treffen kein Platz mehr sein, sondern erst beim nächsten Mal im 27.09.2017. * Startzeit und Ort: Wir treffen uns um 18:00 Uhr im Bürgerhaus in den Düsseldorfer Arcaden. Das Bürgerhaus teilt sich den Eingang mit dem Schwimmbad und befindet sich an der Seite der Tiefgarageneinfahrt der Düsseldorfer Arcaden. Über dem Eingang steht ein großes "Schwimm' in Bilk" Logo. Hinter der Tür direkt links zu den zwei Aufzügen, dann in den 2. Stock hochfahren. Der Eingang zum Raum 1 liegt direkt links, wenn man aus dem Aufzug kommt. Google Street View: http://bit.ly/11sCfiw ________________________________________________________________________ EINLEITUNG Das Python Meeting Düsseldorf ist eine regelmäßige Veranstaltung in Düsseldorf, die sich an Python Begeisterte aus der Region wendet: * http://pyddf.de/ Einen guten Überblick über die Vorträge bietet unser YouTube-Kanal, auf dem wir die Vorträge nach den Meetings veröffentlichen: * http://www.youtube.com/pyddf/ Veranstaltet wird das Meeting von der eGenix.com GmbH, Langenfeld, in Zusammenarbeit mit Clark Consulting & Research, Düsseldorf: * http://www.egenix.com/ * http://www.clark-consulting.eu/ ________________________________________________________________________ PROGRAMM Das Python Meeting Düsseldorf nutzt eine Mischung aus (Lightning) Talks und offener Diskussion. Vorträge können vorher angemeldet werden, oder auch spontan während des Treffens eingebracht werden. Ein Beamer mit XGA Auflösung steht zur Verfügung. (Lightning) Talk Anmeldung bitte formlos per EMail an info(a)pyddf.de ________________________________________________________________________ KOSTENBETEILIGUNG Das Python Meeting Düsseldorf wird von Python Nutzern für Python Nutzer veranstaltet. Um die Kosten zumindest teilweise zu refinanzieren, bitten wir die Teilnehmer um einen Beitrag in Höhe von EUR 10,00 inkl. 19% Mwst, Schüler und Studenten zahlen EUR 5,00 inkl. 19% Mwst. Wir möchten alle Teilnehmer bitten, den Betrag in bar mitzubringen. ________________________________________________________________________ ANMELDUNG Da wir nur für ca. 20 Personen Sitzplätze haben, möchten wir bitten, sich per EMail anzumelden. Damit wird keine Verpflichtung eingegangen. Es erleichtert uns allerdings die Planung. Meeting Anmeldung bitte formlos per EMail an info(a)pyddf.de ________________________________________________________________________ WEITERE INFORMATIONEN Weitere Informationen finden Sie auf der Webseite des Meetings: http://pyddf.de/ Mit freundlichen Grüßen, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Sep 26 2017) >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>> Python Database Interfaces ... http://products.egenix.com/ >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ ________________________________________________________________________ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/

1 0

File aus Datadir kopieren
by Sascha Manns 24 Sep '17

24 Sep '17

Hallo liste, gerade schreibe ich ein Python3 Programm, welches durch Makefiles installiert wird. Somit können Applikationsdaten sowohl unter /usr/share, als auch unter /usr/local/share liegen. Nun möchte ich ein File aus diesem Ordner an ein Ziel kopieren. Wie kann ich am Besten darauf zugreifen? Gruß Sascha -- Sascha Manns | openSUSE Member Email: saigkill(a)opensuse.org | Blog: http://saigkill.tuxfamily.org GPG: 0x62ECD463

2 2

Projektmanagement per Web (für Dummies)
by Thomas Güttler 21 Sep '17

21 Sep '17

Hallo, das ist etwas off-topic, aber vielleicht doch interessant ... Ich habe bei einem Projekt vier Gruppen: - Softwareentwickler - Teamleiter der Softwareentwickler - Anwender der Software - Teamleiter der Anwender Die ersten zwei sind angestellt beim Dienstleister, die anderen zwei sind "Kunden". Für die Details haben wir ein Ticketsystem, das ist kein Problem. Aber für die High-Level-Sicht fehlt mir derzeit ein passendes Tool. Gantt Diagramme wäre schon schön. Also zB "Mit B kann es erst los gehen, wenn A fertig ist". Es sollte webbasiert sein. Wichtig ist eine gemeinsame Sicht... Wenn man nach "web gantt project management" sucht, findet man endlos viele Treffer. Hat hier jemand einen Tipp? Wie schafft ihr Übersicht bei größeren Software-Projekten? 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] strings zusammensetzen.
by Peter J. Holzer 17 Sep '17

17 Sep '17

On 2017-09-16 08:33, Stefan Behnel <python-de(a)behnel.de> wrote: > Peter J. Holzer schrieb am 16.09.2017 um 09:28: >> (String-Konkatenation ist in Python(3) zumindest bei langen Strings auch >> schön linear) > > Es gibt sowohl für bytes-Objekte als auch für Unicode-Strings eine > Sonderbehandlung, die realloc() verwendet. Auf vielen Platformen ist > realloc() effizient und führt im Durchschnitt zu einer linearen Laufzeit > auch bei mehreren Konkatenierungen. Aber nicht auf allen. Ineffiziente Plattformen sollte man meiden :-). Allerdings ist das eher eine Frage, wie Python damit umgeht als wie gut die Malloc- Implementation ist - obwohl eine gute Malloc-Implementation gewisse Schwächen im Interpreter gut übertünchen kann (wie eine Diskussion zum gleichen Thema in Perl vor ein paar Jahren gezeigt hat). > Außerdem greift die Optimierung nicht in allen Fällen. Beispielsweise hast > du Pech, wenn über die Konkatenierungen hinweg der Zeichenraum erst von > ASCII auf BMP und dann auf Astral wechselt. Dann muss beim Wechsel der > komplette bisherige String doch wieder im Speicher herum kopiert werden. Das dürfte weitgehend vernachlässigbar sein, weil es maximal 2 solche Übergänge geben kann. Also viel weniger als die Kopiervorgänge, die üblicherweise tatsächlich stattfinden, weil realloc nicht in-place expandieren kann. > Also kurz: join() ist in jedem Fall die bessere Variante bei vielen > Strings. Konkatenierung ist ok bei einer überschaubaren Menge und da > insbesondere bei kurzen Strings, sollte aber in Schleifen vermieden werden. Du vergisst, dass Listen einen nicht zu vernachlässigbaren Memory-Overhead haben. Gerade bei langen Listen sollte man darauf verzichten, sie aufzubauen, wenn man sie nicht unbedingt braucht (habe damit erst kürzlich 8 GB eingespart - pro Prozess (das war Perl und nicht Python, aber die beiden Sprachen sind sich da sehr ähnlich)). Kleiner Test: ------------------------------------------------------------------------ #!/usr/bin/python3 import sys import time n = int(sys.argv[1]) t0 = time.clock_gettime(time.CLOCK_MONOTONIC) s = "" for i in range(n): s += str(i) t1 = time.clock_gettime(time.CLOCK_MONOTONIC) print(n, t1-t0, n / (t1 - t0)) ------------------------------------------------------------------------ ------------------------------------------------------------------------ #!/usr/bin/python3 import sys import time n = int(sys.argv[1]) tick_size = 1000000 t0 = time.clock_gettime(time.CLOCK_MONOTONIC) elems = [] for i in range(n): elems.append(str(i)) s = "".join(elems) t1 = time.clock_gettime(time.CLOCK_MONOTONIC) print(n, t1 - t0, n / (t1 - t0)) ------------------------------------------------------------------------ Ergebnis: Performance ist praktisch gleich, aber auf einer 32-Bit-Maschine kommt die Konkatenierungsversion gut 3 mal so weit, bevor sie am Memory-Limit anstößt. (Graphik auf <http://www.hjp.at/programming/python/concat-vs-join/>) 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

3 5

Re: [Python-de] strings zusammensetzen.
by Peter J. Holzer 17 Sep '17

17 Sep '17

On 2017-09-17 06:19, Stefan Behnel <python-de(a)behnel.de> wrote: > Peter J. Holzer schrieb am 16.09.2017 um 22:46: >> Gerade bei langen Listen sollte man darauf verzichten, sie >> aufzubauen, wenn man sie nicht unbedingt braucht > > Natürlich. Einzig darauf zielt dein Beispielcode ja auch ab. > > Gilt übrigens genauso für lange Strings. Natürlich. Wenn man den langen String nie braucht, soll man ihn auch nicht aufbauen. Gerade, wenn der String an einen Konsumenten geschickt werden soll, der ihn dann gleich wieder parst, hat man auch noch den Vorteil, dass Produzent und Konsument sich zeitlich überlappen können, wenn der Produzent Teile des Outputs so früh wie möglich schickt. Geht aber leider nicht immer: Manche Protokolle brauchen z.B. eine Längenangabe im Header und dafür muss man den Output erst mal komplett haben, um die Länge bestimmen zu können. >> (habe damit erst kürzlich 8 GB eingespart - pro Prozess (das war Perl >> und nicht Python, aber die beiden Sprachen sind sich da sehr >> ähnlich)). > > Wie du hier korrekt andeutest, handelt es sich bei dem gegebenen Fall um > eine Optimierung. Optimierung bedeutet ja, dass du eigentlich gut > geschriebenen Code ersetzt durch etwas, was dem spezifischen Anwendungsfall > stärker angepasst ist und (nachweislich) unter den erwarteten Bedingungen > effizienter funktioniert. Mit dem Risiko, dass es unter anderen (eben nicht > erwarteten) Bedingungen vielleicht auch weniger gut funktioniert. Richtig. Wobei in diesem Fall allerdings beide Varianten von der Code-Länge und Lesbarkeit her ziemlich vergleichbar waren. Im Gegensatz zu manchen anderen Fällen, wo es klar eine "saubere" und eine optimierte Variante gibt, gab es hier zwei Varianten, die zwar verschiedenen Ansätzen (eher prozedural und eher funktional) folgten, aber (für meinen Geschmack) beide gleich sauber waren. Da dann die Variante zu wählen, die weniger Speicher braucht und schneller ist, ist ein No-Brainer (und ja, ich habe beide Varianten gebenchmarkt, bevor ich die Änderung durchgeführt habe). Bei dem kleinen Test-Programm sehe ich das ähnlich: Die Variante mit join ist *nicht* klar sauberer. Eher im Gegenteil: Sie baut explizit eine unnötige Datenstruktur auf, das empfinde ich als unelegant. (Etwas anderes ist es, wenn die Datenstruktur nur implizit aufgebaut wird: Mit map statt der explizitien Schleife (was bei diesem Trivialbeispiel natürlich leicht möglich gewesen wäre) wäre der Code für mich eindeutig eleganter und damit wäre eine möglich Optimierung nur sinnvoll, wenn die positiven Effekte zur Laufzeit die negativen Effekte für den Programmierer überwiegen.) Aber im wesentlichen ging es mir eben um Deine dogmatisch vorgetragene Aussage: | join() ist in jedem Fall die bessere Variante bei vielen Strings. Das sehe ich eben nicht so. Gerade bei vielen Strings gibt es Fälle, wo es besser ist, den String stückweise in einer Schleife aufzubauen. | Konkatenierung ist ok bei einer überschaubaren Menge und da | insbesondere bei kurzen Strings, sollte aber in Schleifen vermieden | werden. Und wie nun ausführlich begründet, sehe ich das genau umgekehrt: Bei kurzen Strings, die aus wenigek Komponenten zusammengesetzt werden, ist beides Ok. Bei langen Strings, die aus vielen Komponenten aufgebaut werden, sollte man sich überlegen, ob nicht eine explizite Schleife besser ist als ein Join. 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

strings zusammensetzen.
by Hermann Riemann 16 Sep '17

16 Sep '17

Was ist besser? a b und c enthalten strings. d=a+b+c besser als d="{}{}{}".format(a,b,c) ? Hermann der hier nicht an Lesbarkeit denkt. -- http://www.hermann-riemann.de

8 13

Re: [Python-de] strings zusammensetzen.
by Peter J. Holzer 16 Sep '17

16 Sep '17

On 2017-08-31 13:26, Peter Otten <__peter__(a)web.de> wrote: > Hermann Riemann wrote: > >> Allerdings fällt mir bei der Gelegenheit ein, >> was ist, wenn der Dateiname ein bytestring ist, >> der sich nicht nach utf konvertieren lässt? >> In C ist ja als Dateiname alles außer '/' und '\0' erlaubt. > > Unter Linux kein Problem: > >>>> import os >>>> ord("/") > 47 >>>> filename = bytes(c for c in range(1, 256) if c != 47) >>>> filename > b'\x01\x02\x03\x04\x05\x06\x07\x08\t\n\x0b\x0c\r\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f > !"#$%&\'()*+,-.0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~\x7f\x80\x81\x82\x83\x84\x85\x86\x87\x88\x89\x8a\x8b\x8c\x8d\x8e\x8f\x90\x91\x92\x93\x94\x95\x96\x97\x98\x99\x9a\x9b\x9c\x9d\x9e\x9f\xa0\xa1\xa2\xa3\xa4\xa5\xa6\xa7\xa8\xa9\xaa\xab\xac\xad\xae\xaf\xb0\xb1\xb2\xb3\xb4\xb5\xb6\xb7\xb8\xb9\xba\xbb\xbc\xbd\xbe\xbf\xc0\xc1\xc2\xc3\xc4\xc5\xc6\xc7\xc8\xc9\xca\xcb\xcc\xcd\xce\xcf\xd0\xd1\xd2\xd3\xd4\xd5\xd6\xd7\xd8\xd9\xda\xdb\xdc\xdd\xde\xdf\xe0\xe1\xe2\xe3\xe4\xe5\xe6\xe7\xe8\xe9\xea\xeb\xec\xed\xee\xef\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf7\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff' >>>> os.path.exists(filename) > False >>>> with open(filename, "w") as f: f.write("yadda\n") > ... > 6 >>>> os.path.exists(filename) > True >>>> os.listdir() > ['\x01\x02\x03\x04\x05\x06\x07\x08\t\n\x0b\x0c\r\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f > !"#$%&\'()*+,-.0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~\x7f\udc80\udc81\udc82\udc83\udc84\udc85\udc86\udc87\udc88\udc89\udc8a\udc8b\udc8c\udc8d\udc8e\udc8f\udc90\udc91\udc92\udc93\udc94\udc95\udc96\udc97\udc98\udc99\udc9a\udc9b\udc9c\udc9d\udc9e\udc9f\udca0\udca1\udca2\udca3\udca4\udca5\udca6\udca7\udca8\udca9\udcaa\udcab\udcac\udcad\udcae\udcaf\udcb0\udcb1\udcb2\udcb3\udcb4\udcb5\udcb6\udcb7\udcb8\udcb9\udcba\udcbb\udcbc\udcbd\udcbe\udcbf\udcc0\udcc1\udcc2\udcc3\udcc4\udcc5\udcc6\udcc7\udcc8\udcc9\udcca\udccb\udccc\udccd\udcce\udccf\udcd0\udcd1\udcd2\udcd3\udcd4\udcd5\udcd6\udcd7\udcd8\udcd9\udcda\udcdb\udcdc\udcdd\udcde\udcdf\udce0\udce1\udce2\udce3\udce4\udce5\udce6\udce7\udce8\udce9\udcea\udceb\udcec\udced\udcee\udcef\udcf0\udcf1\udcf2\udcf3\udcf4\udcf5\udcf6\udcf7\udcf8\udcf9\udcfa\udcfb\udcfc\udcfd\udcfe\udcff'] > > Hier sieht man, was mit nicht dekodierbaren Bytes geschieht -- Python > verwendet den surrogate-escape error handler: > >>>> b"\xf1\xf2\xf3".decode("utf-8", "surrogateescape") > '\udcf1\udcf2\udcf3' >>>> > > Die Shell kann da nicht mithalten: > > [2]+ Angehalten python3 > $ ls > ??????????????????????????????? > !"#$%&'()*+,-.0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? Die Shell ist da gar nicht beteiligt. Die ruft ja nur "ls" auf. Der Output, den Du da zitierst, stammt von ls, und das ersetzt per default in der Ausgabe nicht-druckbare Zeichen durch "?" (das ist ein Feature - man will in einem Terminal nicht, das ls irgendwelche Escape-Codes ausgeben kann, nur weil der Ersteller eines Files lustig war). Es gibt Optionen, um die Ausgabe zu ändern, z.B. auf (oktale) Escape-Codes: % ls -b \001\002\003\004\005\006\a\b\t\n\v\f\r\016\017\020\021\022\023\024\025\026\027\030\031\032\033\034\035\036\037\ !"#$%&'()*+,-.0123456789:;<\=\>?\@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{\|}~\177\200\201\202\203\204\205\206\207\210\211\212\213\214\215\216\217\220\221\222\223\224\225\226\227\230\231\232\233\234\235\236\237\240\241\242\243\244\245\246\247\250\251\252\253\254\255\256\257\260\261\262\263\264\265\266\267\270\271\272\273\274\275\276\277\300\301\302\303\304\305\306\307\310\311\312\313\314\315\316\317\320\321\322\323\324\325\326\327\330\331\332\333\334\335\336\337\340\341\342\343\344\345\346\347\350\351\352\353\354\355\356\357\360\361\362\363\364\365\366\367\370\371\372\373\374\375\376\377 Die Shell (zumindest die zsh, und ich nehme an, die bash auch nicht), hat kein Problem mit solchen Filenamen: % rm $'\001'$'\002'$'\003'$'\004'$'\005'$'\006'$'\a'$'\b'$'\t'$'\n'$'\v'$'\f'$'\r'$'\016'$'\017'$'\020'$'\021'$'\022'$'\023'$'\024'$'\025'$'\026'$'\027'$'\030'$'\031'$'\032'$'\033'$'\034'$'\035'$'\036'$'\037'\ \!\"\#\$%\&\'\*+,-.0123456789:\;\<=\>\?@ABCDEFGHIJKLMNOPQRSTUVWXYZ\[\\\]\^_\`abcdefghijklmnopqrstuvwxyz\{\|\}\~$'\177'$'\200'$'\201'$'\202'$'\203'$'\204'$'\205'$'\206'$'\207'$'\210'$'\211'$'\212'$'\213'$'\214'$'\215'$'\216'$'\217'$'\220'$'\221'$'\222'$'\223'$'\224'$'\225'$'\226'$'\227'$'\230'$'\231'$'\232'$'\233'$'\234'$'\235'$'\236'$'\237'$'\240'$'\241'$'\242'$'\243'$'\244'$'\245'$'\246'$'\247'$'\250'$'\251'$'\252'$'\253'$'\254'$'\255'$'\256'$'\257'$'\260'$'\261'$'\262'$'\263'$'\264'$'\265'$'\266'$'\267'$'\270'$'\271'$'\272'$'\273'$'\274'$'\275'$'\276'$'\277'$'\300'$'\301'$'\302'$'\303'$'\304'$'\305'$'\306'$'\307'$'\310'$'\311'$'\312'$'\313'$'\314'$'\315'$'\316'$'\317'$'\320'$'\321'$'\322'$'\323'$'\324'$'\325'$'\326'$'\327'$'\330'$'\331'$'\332'$'\333'$'\334'$'\335'$'\336'$'\337'$'\340'$'\341'$'\342'$'\343'$'\344'$'\345'$'\346'$'\347'$'\350'$'\351'$'\352'$'\353'$'\354'$'\355'$'\356'$'\357'$'\360'$'\361'$'\362'$'\363'$'\364'$'\365'$'\366'$'\367'$'\370'$'\371'$'\372'$'\373'$'\374'$'\375'$'\376'$'\377' (ich habe da einfach rm<space><tab> getippt, und die Expansion des Namens, den ich nicht tippen will, der Shell überlassen) Und weg is: % ls % > Unter Windows sind die Regeln wohl etwas komplexer. Ja. Einerseits, weil es mehr reservierte Zeichen gibt, die entweder gar nicht oder nur an bestimmten Stellen vorkommen dürfen. Andererseits, weil Filenamen in NTFS keine Byte-Strings sind, sondern UTF-16-Strings. 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

python-de September 2017