Was wünscht ihr euch in die Standardlib?

Alles, was nicht direkt mit Python-Problemen zu tun hat. Dies ist auch der perfekte Platz für Jobangebote.
lunar

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.
Y0Gi
User
Beiträge: 1454
Registriert: Freitag 22. September 2006, 23:05
Wohnort: ja

docutils, simplejson, pyyaml.
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

docutils
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

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

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
birkenfeld
Python-Forum Veteran
Beiträge: 1603
Registriert: Montag 20. März 2006, 15:29
Wohnort: Die aufstrebende Universitätsstadt bei München

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.
Dann lieber noch Vim 7 als Windows 7.

http://pythonic.pocoo.org/
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

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.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Y0Gi
User
Beiträge: 1454
Registriert: Freitag 22. September 2006, 23:05
Wohnort: ja

Ich vergaß: PIL!!1einselfelf
EnTeQuAk
User
Beiträge: 986
Registriert: Freitag 21. Juli 2006, 15:03
Wohnort: Berlin
Kontaktdaten:

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
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

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?

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

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. :shock: 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
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
birkenfeld
Python-Forum Veteran
Beiträge: 1603
Registriert: Montag 20. März 2006, 15:29
Wohnort: Die aufstrebende Universitätsstadt bei München

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. :shock: 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.
Dann lieber noch Vim 7 als Windows 7.

http://pythonic.pocoo.org/
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

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
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
birkenfeld
Python-Forum Veteran
Beiträge: 1603
Registriert: Montag 20. März 2006, 15:29
Wohnort: Die aufstrebende Universitätsstadt bei München

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.
Dann lieber noch Vim 7 als Windows 7.

http://pythonic.pocoo.org/
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

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

lg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
lunar

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. :shock: 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.
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

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... :mrgreen:

lg
Gerold
:-)

PS: Ich erinnere daran, dass wir hier im Offtopic-Forum sind. ;-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
BlackJack

Ist schon okay. Lisp ist schon eine schöne Sprache. Oder von welcher hast Du gerade geschwärmt!? ;-)
Benutzeravatar
BlackVivi
User
Beiträge: 762
Registriert: Samstag 9. Dezember 2006, 14:29
Kontaktdaten:

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)
Y0Gi
User
Beiträge: 1454
Registriert: Freitag 22. September 2006, 23:05
Wohnort: ja

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.
lunar

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.
Antworten