Das deutsche Python-Forum

BlackVivi hat geschrieben:Gut, im Endeffekt hab ich darüber nachgedacht und bin zu einem ähnlichen Entschluss gekommen wie ihr es mir (wesentlich schlüssiger) erklärt habt.

Als Beispiel, damit ich's versteh... ich lern ja noch:

Ich mach'n supertolles Programm das supertolle Sachen kann, beispielsweise automatisch Dateien umbenennen nach das und das und verteil das in meinem Netzwert/Online. In diesem pack ich so einen Online Import dingens (Entschuldigt den Ausdruck) und der macht erstmal gar nüx, also importiert eine leere .py Datei.

Nach einiger Zeit, wenn's verteilt genug ist, pack ich da wunderschönen schadhaften Quellcode rein und tada, alles putt.

Zum Beispiel. Du kannst aber auch das Opfer sein: In gutem Glauben importierst du in deiner Anwendung ein Modul über diesem Mechanismus von einem zentralen Server (um z.B. Softwareupdates zu erleichtern). Jetzt bricht jemand in den Server ein, und hat so über den Austausch des Moduls auch automatisch alle Clients unter Kontrolle.

docutils, simplejson, pyyaml.

docutils

Vielleicht sollte man mal ein Voting einführen und es werden dann die externen Module aufgenommen, die von den meisten Leuten gewünscht werden.

So läuft das sicher nicht...

Erst mal sind Libraries, die sich noch schnell ändern (so wie docutils), keine Kandidaten für Python mit einem (angestrebten) Releasezyklus von 18 Monaten.

Dann braucht es einen Maintainer, der sich aktiv um die Library in der stdlib kümmert und das auch für eine gewisse Zeit kann.

Und schließlich sind Libraries ab einer gewissen Größe (so wie docutils) einfach zu viel für die stdlib.

simplejson oder eine Yaml-Implementierung halte ich dagegen für möglich, wenn auch pyyaml nicht besonders "mature" ist.

birkenfeld hat geschrieben:simplejson oder eine Yaml-Implementierung halte ich dagegen für möglich, wenn auch pyyaml nicht besonders "mature" ist.

simplejson halte ich auch für recht unproblematisch, jedoch war PyYaml in der Vergangenheit ein ziemliches Problem, da dort irgendwann zig Forks entstanden sind und der Maintainer verloren gegangen ist.

Ist aber vermutlich immer noch besser als Syck und PySyck.

Ich vergaß: PIL!!1einselfelf

Also docutils ist klar, einfach zu groß. Glücklicher Weise wird es von so vielen Projekten benutzt, das es auf vielen Rechnern einfach installiert ist.

Aber was ich mir in die stdlib wünsche, ist wirklich simplejson. Das ist so klein und fein, da würde ich mich tierisch drüber freuen.

Eventuell noch BeautifulSoap, das währe noch brauchbar. Ansonsten bin ich sehr zufrieden.

Achso! --> ConfigObj könnte den ConfigParser ersetzen, das währe auf jedenfall eine Verbesserung


MfG EnTeQuAk

birkenfeld hat geschrieben:Erst mal sind Libraries, die sich noch schnell ändern (so wie docutils), keine Kandidaten für Python mit einem (angestrebten) Releasezyklus von 18 Monaten.

Dann braucht es einen Maintainer, der sich aktiv um die Library in der stdlib kümmert und das auch für eine gewisse Zeit kann.

Und schließlich sind Libraries ab einer gewissen Größe (so wie docutils) einfach zu viel für die stdlib.

Man sollte natürlich erstmal eine Vorsortierung vornehmen. Also im Vorfeld schon gewisse Module ausschließen.
Ansonsten wäre es doch Sinnvoll gerade die Module aufzunehmen, die von den meisten gewünscht werden, oder?

EnTeQuAk hat geschrieben:Also docutils ist klar, einfach zu groß.
[...]
ConfigObj könnte den ConfigParser ersetzen

Hallo EnTeQuAk!

Egal wie groß die Docutils sind. Die gehören einfach rein ins Standard-Python. Hört mich jemand!?

Ersetzen würde ich ihn nicht, den ConfigParser, denn ConfigObj liefert keine "Standard"-INI-Dateien zurück die auch von anderen Programmen gelesen werden können. Der ConfigParser hält sich an die Vorgaben von Microsoft. --> Die INI-Dateien sind mit den API-Funktionen "GetPrivateProfileXXX" lesbar und mit "WritePrivateProfileXXX" schreibbar. Das ist mit ConfigObj-Dateien nicht mehr möglich.

lg
Gerold

gerold hat geschrieben:

EnTeQuAk hat geschrieben:Also docutils ist klar, einfach zu groß.
[...]
ConfigObj könnte den ConfigParser ersetzen

Hallo EnTeQuAk!

Egal wie groß die Docutils sind. Die gehören einfach rein ins Standard-Python. Hört mich jemand!?

Wie schon gesagt: sogar wenn die Größe akzeptiert würde, API-Stabilität ist bei docutils praktisch nicht vorhanden, und das ist ein Ausschlusskriterium.

birkenfeld hat geschrieben:sogar wenn die Größe akzeptiert würde, API-Stabilität ist bei docutils praktisch nicht vorhanden, und das ist ein Ausschlusskriterium.

Hallo birkenfeld!

Und ich dachte, dass sich schon seit mindestens einem Jahr nichts mehr geändert hat was sich auf die Schnittstelle nach außen auswirkt. So kann man falsch liegen.

lg
Gerold

gerold hat geschrieben:

birkenfeld hat geschrieben:sogar wenn die Größe akzeptiert würde, API-Stabilität ist bei docutils praktisch nicht vorhanden, und das ist ein Ausschlusskriterium.

Hallo birkenfeld!

Und ich dachte, dass sich schon seit mindestens einem Jahr nichts mehr geändert hat was sich auf die Schnittstelle nach außen auswirkt. So kann man falsch liegen.

Zumindest ist zwischen 0.4 und SVN ein ziemlicher Unterschied.

birkenfeld hat geschrieben:Zumindest ist zwischen 0.4 und SVN ein ziemlicher Unterschied.

...schade

lg
Gerold

gerold hat geschrieben:

EnTeQuAk hat geschrieben:Also docutils ist klar, einfach zu groß.
[...]
ConfigObj könnte den ConfigParser ersetzen

Hallo EnTeQuAk!

Egal wie groß die Docutils sind. Die gehören einfach rein ins Standard-Python. Hört mich jemand!?

Ersetzen würde ich ihn nicht, den ConfigParser, denn ConfigObj liefert keine "Standard"-INI-Dateien zurück die auch von anderen Programmen gelesen werden können

Das kann ich schwer glauben. Wenn man auf configobj Features wie verschachtelte Sektionen verzichtet, sondern immer brav nur eine Ebene verwendet, und dann auch alle Werte immer brav in Sektionen ablegt, sehen die Resultate genau aus wie ConfigParser-Dateien.

Allerdings habe ich auch keine Ahnung, wie "Standard-INI-Dateien" aussehen. Allerdings sind die auch nicht mehr so Standard wie sie mal waren. .NET verwendet keine INIs mehr, und enthält iirc noch nicht mal Klassen, um sie zu lesen.

lunar hat geschrieben:Allerdings sind die auch nicht mehr so Standard wie sie mal waren. .NET verwendet keine INIs mehr

Hallo lunar!

Ja, Microsoft macht die letzen Jahre immer mehr einschneidende Fehler! Sie verkomplizieren das System immer mehr. Ich habe lange Zeit, wie von MS empfohlen, mit der Registry gearbeitet.
Irgendwann habe ich mir dann auf den Kopf gegriffen und mich gefragt warum ich mir den Scheiß überhaupt an tu.

Später habe ich mich in .NET eingearbeitet und ca. ein oder zwei Jahre lang damit programmiert.
Irgendwann habe ich mich gefragt, warum z.B. der Datenbankzugriff auf einmal so aufwändig geworden ist. Und wieder habe ich mir auf den Kopf gegriffen und mich gefragt warum ich mir den Scheiß überhaupt an tu.

Ich wurde immer unzufriedener je mehr ich mich mit Linux beschäftigte. Ich begann die Freiheit zu spüren. Eine Freiheit, die ich vorher nie für möglich gehalten hatte. Jetzt suchte ich natürlich eine Programmiersprache, die mir die neu gewonnene Freiheit versüßen würde. Nach vielem Ausprobieren und einem kurzen Abstecher in die C++-Welt habe ich sie gefunden. Eine Sprache, mit der ich Linux- und Windowsprogramme schreiben kann. Eine Sprache, in der ein Quellcode schon fast von alleine ein strahlendes Kunstwerk ist. Eine Sprache...

Was ist los Jungs? War ich zu laut? -- Nein, nicht schon wieder diese Elektroschocks! Ich hatte heute schon zwei Behandlungen...

lg
Gerold


PS: Ich erinnere daran, dass wir hier im Offtopic-Forum sind.

Ist schon okay. Lisp ist schon eine schöne Sprache. Oder von welcher hast Du gerade geschwärmt!?

BlackJack hat geschrieben:Ist schon okay. Lisp ist schon eine schöne Sprache. Oder von welcher hast Du gerade geschwärmt!?

Bestimmt VB6.

*scnr*

(Wenn ich so recht überleg, VB6 is'n Kunstwerk. Ein Modernes, abstraktes und furchtbares, dass in der Besenkammer des Louvre hängt und dessen unglaublich abstrakte Struktur absolut jeden ehrwürdigen Kunstkenner in Rage bringt, ABER ein Kunstwerk.

Hab'n kleinen Hass gegenüber VB6, verzeiht mir)

Ich halte JSON und YAML übrigens für brauchbare Alternativen zu .ini-Dateien und in Projekten wie Rails erfreuen sich derlei Formate großer Beliebtheit - als Alternative zu XML, das schon deutlich flexibler als .ini ist.

Y0Gi hat geschrieben:Ich halte JSON und YAML übrigens für brauchbare Alternativen zu .ini-Dateien und in Projekten wie Rails erfreuen sich derlei Formate großer Beliebtheit - als Alternative zu XML, das schon deutlich flexibler als .ini ist.

Naja, diese Format kann man ohne kompletten Parser kaum mehr verarbeiten. Für INI-Dateien dagegen reichen auch grep, sed, gawk und Konsorten, wodurch man auch mal eben in der Shell einen Konfigurationswert auslesen kann.