Python Texteditor

[jens]

Das sehe ich anders

Zum einen, sollte man sys.platform.startswith(...) benutzen. Außerdem sind die Keys bei snafu Variante nicht brauchbar, siehe auch: http://docs.python.org/library/sys.html#sys.platform

Zum anderen finde ich bei mir besser, das die "Konfigurations"-Daten oben im skript stehen würden. Das macht gerade bei solchen Dingen Sinn. (Ich packe sowas immer direkt unter den imports)

[snafu]

Ich verwende platform.system() und da sind die Schlüsselnamen durchaus brauchbar. Ich frage mich auch, wie du darauf kommst, dass man nur `sys.platform` verwenden soll.

Und das Dictionary kann man *natürlich* auch außerhalb der Funktion haben. Finde die Argumentation ehrlich gesagt etwas zu dürftig, als dass sie mich überzeugen würde. Ich halte meine Variante jedenfalls für lesbarer und verständlicher, wie Nobuddy schon sagte. Sofern dir kein *echter* Nachteil einfällt, sehe ich auch nicht, wieso man sie deshalb nicht benutzen sollte. Ich will sie ja keinem aufzwingen, frage mich aber, wieso davon abgeraten wird.

[jens]

Ich verwende platform.system()

Das habe ich doch glatt übersehen

Hab mir mal den Code zu dem angeschaut: http://hg.python.org/cpython/file/2.7/Lib/platform.py
Ist also letztlich das was os.uname() als erstes zurück liefert.

Über die Unterschiede zwischen sys.platform, os.name und platform.system() gibt es z.B. hier info's:
http://stackoverflow.com/questions/4553 ... orm-system

Vielleicht ist es sogar ratsam os.name zu nutzten? -> http://docs.python.org/library/os.html#os.name Denn dabei hat man "feste" mögliche Werte.

Oder noch anders gelöst: Nicht den OS Namen nehmen, sondern zu prüfen, ob "start", "xdg-open" oder "open" verfügbar ist?

EDIT: Interessant ist auch: http://stackoverflow.com/questions/1854 ... running-on
Würde mich mal interessieren, ob es eine vollständige Tabelle mit sys.platform, os.name und platform.system() für alle möglichen Platformen gibt...

[snafu]

Oder noch anders gelöst: Nicht den OS Namen nehmen, sondern zu prüfen, ob "start", "xdg-open" oder "open" verfügbar ist?

Ginge natürlich auch. Wobei ich da ein bißchen Bauchschmerzen hinsichtlich potenzieller Namenskollisionen hätte. Also dass es zufällig ein Linux-Tool gibt, das `start` heißt, aber etwas ganz anderes tut, oder sowas. Da müsste man dann schon auf Verhalten testen, oder z.B. gucken, was von `--help` zurückgegeben wird. Klingt mir - wenn man es ordentlich machen will - etwas zu kompliziert für diese Aufgabe.

`os.name` dürfte auch relativ robust sein. Nähere Details will man ja meist gar nicht wissen und man hätte auch dort keine hässliche `.startswith()`-Verzweigung, sondern könnte beim Dict bleiben. Allerdings ist es halt nicht ganz so lesbar wie `platform.system()` und daher für mich persönlich nur an zweiter Stelle. Etwas irritierend ist, dass es zu `platform.system()` anscheinend keine ordenliche Doku gibt, wo alle möglichen Werte drinstehen.

/edit: Es gibt unter Linux tatsächlich das Kommando `start`.

[jens]

anscheinend keine ordenliche Doku gibt, wo alle möglichen Werte drinstehen.

Dann last uns doch mal selber sammeln!

Ich hab eine Wiki Seite gestartet:
http://wiki.python.de/platform%20unterscheiden

[Nobuddy]

@jens, die Ausgabe von:

Code: Alles auswählen

platform.platform()

gefällt mir besser als

Code: Alles auswählen

platform.uname()

Da sind vor allem die wichtigen Angaben enthalten und alles andere Unnütze fehlt dort.

PS: Nachtrag
Aber die Infos lassen sich bei 'platform.uname()' ermitteln.

[snafu]

Ich hab eine Wiki Seite gestartet:
http://wiki.python.de/platform%20unterscheiden

Die Ergebnisse sprechen IMHO dafür, dass `os.name` keine so gute Idee ist. Denn eine Darwin-Platform spuckt `posix` aus, aber dort soll wohl eher kein `xdg-open` benutzt werden. Wahrscheinlich müsste man dann irgendwie mehrere Bedingungen überprüfen. Mich bestärkt das jedenfalls in meiner Auffassung, dass `platform.system()` oft die bessere Wahl ist. Und falls z.B. weitere Plattformen `xdg-open` draufhaben, aber `platform.system()` für diese nicht `Linux` liefert, so kann man immer noch weitere Schlüssel einfügen, die als Wert ebenfalls `xdg-open` tragen (um beim Beispiel zu bleiben). Das mag theoretisch dem Programmersteller unbekannte, aber eigentlich geeignete exotische Plattformen ausschlieißen, aber dafür kommt es nicht zu irgendwelchen False-Positives Entscheidungen. Da empfinde ich mögliches ungewolltes Ausschließen der Exoten immer noch als das geringere Übel.

//edit: Im Übrigen wird sicherlich auch nicht jede Linux-Plattform zwangsläufig `xdg-open` vorinstalliert haben. Letztlich wäre es vielleicht schlau, nach Ermitteln des vermuteten Starters auch tatsächlich auf sein Vorhandensein zu prüfen.