Ich habe das Blogposting "python3 is fine" http://sealedabstract.com/rants/python-3-is-fine/ von Drew Crawford ins Deutsche übersetzt und darf die Übersetzung unter creative-commons cc-by-sa Lizenz publizieren. (Somit darf das auch jeder andere)
Falls jemand Korrektur lesen möchte würde ich mich sehr freuen:
https://github.com/horstjens/RISJournal ... isfine.txt
Übersetzung von "python3 is fine" Blogposting ins Deutsche
-
BlackJack
Python 3 mag „fine” sein, für mich leider nur unbenutzbar. Und die Python 3 Proponenten kotzen mich in letzter Zeit einfach nur noch an, weil sie statt Verständnis oder Vorschlägen zu bringen, einfach nur ihre eigene Situation als einzig massgebend ansehen, und ansonsten gerne beleidigen. Der Artikel ist ein „rant”, behauptet also gar nicht erst objektive Argumente zu bringen.
Artikel wie der verkleinern weder die technische Lücke, noch die Gräben zwischen den Benutzern. Im Gegenteil.
Artikel wie der verkleinern weder die technische Lücke, noch die Gräben zwischen den Benutzern. Im Gegenteil.
-
HorstJENS
- User
- Beiträge: 123
- Registriert: Donnerstag 9. Februar 2006, 21:41
- Wohnort: Wien, Österreich
- Kontaktdaten:
Der Artikel bringt sogar 8 verschiedene Vorschläge, und er ist eine Replik auf einen "rant" eines Python2 Benutzers. Du hast nicht zufällig Lust einen dieser Rants ins Deutsche zu übersetzen (und um cc-by-sa Lizenz anzufragen), z.B. https://medium.com/@deliciousrobots/5d2ad703365d/ ?BlackJack hat geschrieben:Python 3 mag „fine” sein, für mich leider nur unbenutzbar. Und die Python 3 Proponenten kotzen mich in letzter Zeit einfach nur noch an, weil sie statt Verständnis oder Vorschlägen zu bringen, einfach nur ihre eigene Situation als einzig massgebend ansehen, und ansonsten gerne beleidigen. Der Artikel ist ein „rant”, behauptet also gar nicht erst objektive Argumente zu bringen.
Artikel wie der verkleinern weder die technische Lücke, noch die Gräben zwischen den Benutzern. Im Gegenteil.
http://spielend-programmieren.at
-
BlackJack
@HorstJENS: Worauf beziehst Du Dich da jetzt speziell? Die von 1 bis 8 nummerierte Liste? Was genau sollen diese Vorschläge bringen?
Und auch wenn er eine Antwort auf einen bestimmten Artikel ist, enthält er trotzdem genug Rundumschläge und Abwertungen in alle Richtungen die nicht-„Python 3 ist wunderbar und hat alles was man braucht, wenn man das nicht sieht ist man zu doof”-Fanatiker betreffen, dass er mehr schadet als nützt. Und er enthält auch nichts neues was nicht schon zum x-ten Mal diskutiert wurde. Das ist einfach nur weiter Öl ins Feuer giessen.
Und auch wenn er eine Antwort auf einen bestimmten Artikel ist, enthält er trotzdem genug Rundumschläge und Abwertungen in alle Richtungen die nicht-„Python 3 ist wunderbar und hat alles was man braucht, wenn man das nicht sieht ist man zu doof”-Fanatiker betreffen, dass er mehr schadet als nützt. Und er enthält auch nichts neues was nicht schon zum x-ten Mal diskutiert wurde. Das ist einfach nur weiter Öl ins Feuer giessen.
-
HorstJENS
- User
- Beiträge: 123
- Registriert: Donnerstag 9. Februar 2006, 21:41
- Wohnort: Wien, Österreich
- Kontaktdaten:
Ich habe die Vorschläge so verstanden "etwas machen anstatt zu nörgeln" (z.B. Geld aufstellen für Fork oder zahlen für Python2-Support Firmenprodukt"). Ich interpretiere Deine Antwort (übersetzen?) als Nein? Schade...BlackJack hat geschrieben:@HorstJENS: Worauf beziehst Du Dich da jetzt speziell? Die von 1 bis 8 nummerierte Liste? Was genau sollen diese Vorschläge bringen?
Und auch wenn er eine Antwort auf einen bestimmten Artikel ist, enthält er trotzdem genug Rundumschläge und Abwertungen in alle Richtungen die nicht-„Python 3 ist wunderbar und hat alles was man braucht, wenn man das nicht sieht ist man zu doof”-Fanatiker betreffen, dass er mehr schadet als nützt. Und er enthält auch nichts neues was nicht schon zum x-ten Mal diskutiert wurde. Das ist einfach nur weiter Öl ins Feuer giessen.
http://spielend-programmieren.at
-
HorstJENS
- User
- Beiträge: 123
- Registriert: Donnerstag 9. Februar 2006, 21:41
- Wohnort: Wien, Österreich
- Kontaktdaten:
@BlackJack Meine Frage ist: Da Du anscheinend keine Lust hast meine Übersetzung korrekturzulesen: Möchtest Du vielleicht den vorausgegangen Rant "python3 is killing python" https://medium.com/@deliciousrobots/5d2ad703365d/ ins Deutsche übersetzen und den Autor um cc-by-sa Lizenz anfragen ? Ich verstehe Deine Postings so dass der Original-Rant mehr in Deinem Sinne ist.BlackJack hat geschrieben:@HorstJENS: Die Antwort verstehe ich nicht.
http://spielend-programmieren.at
-
BlackJack
@HorstJENS: Die sind beide nicht in meinem Sinne. Ich denke nicht das Python 3 sterben wird oder sollte, aber ich sehe auch nicht das mit Python 3 alles so rosig aussieht und vor allem nicht das man so unsachlich sein muss, insbesondere *wenn* damit doch alles so toll ist.
Der Autor hätte wenigstens mal auf die negativen Faktoren, die eine Portierung mit sich bringt, eingehen können. Diese Faktoren sind im Wesentlichen: Kosten, Aufwand, Zeit, Nerven und Risiko. Und diese Faktoren fallen umso mehr ins Gewicht, je größer die Menge an zu portierenden Code ist. Gerade dann, wenn Python in eine bestehende Systemlandschaft integriert wurde - d.h. Abhängigkeiten zu anderen Programmen besitzt -, dann kann es super-übel werden, wenn man plötzlich merkt, dass ein auf Python 3 portiertes Programm unerwartet ein verändertes Verhalten zeigt. Im besten Fall muss man dann "nur" Zeit mit Debugging verbringen; im schlechteren Fall sind irgendwelche gelieferten Daten verfälscht worden. Gut, in der Theorie hat man sich natürlich umfassend durch passende Integrationstests abgesichert - aber tut man das in der Praxis wirklich so umfassend...?
Und auch der Kosten- und Zeitfaktor ist nicht zu unterschätzen: Vor allem, wenn es sich um mehr als ein 200-Zeilen-Hobby-Projekt handelt, fragt man sich zurecht, ob man sich die Mühe wirklich machen möchte, um rein theoretisch die neuen Python-3-Features nutzen zu können, die man aber bisher gar nicht vermisst hatte. Und wenn es um Anwendungen im gewerblichen Bereich geht, dann kommen wie gesagt noch die entsprechenden Kosten dazu. Vorgesetzte, die über die Verteilung des Budgets im Unternehmen entscheiden, neigen dazu, nur dann Geld zu bewilligen, wenn sie die Bearbeitung der Aufgabe als wirklich dringlich und für das Unternehmen förderlich einstufen. Und einem solchen Vorgesetzten soll mal erklärt werden, warum die Mitarbeiter gerade jetzt die nächsten Wochen mit einer Portierung verbringen sollen, wo doch erst kürzlich mitgeteilt wurde, dass die Supportzeit von Python 2.7 deutlich verlängert wird...
Um das klar zu sagen: Auch ich bin kein Gegner von Python 3, aber mit der Zeit ist mir deutlich bewusster geworden, dass eine Portierung in einigen Fällen nicht mal so eben gemacht ist, wie es der Autor des verlinkten Artikels darstellen will. Entweder fehlt ihm dieses Bewusstsein (noch) oder blendet diesen Faktor absichtlich von seiner Argumentation aus. Möglicherweise fällt es bei ihm ja auch in den Bereich "die Probleme der anderen sind nicht unsere Probleme". Dann frage ich mich aber, was der Artikel eigentlich bezwecken soll. Wirklich konstruktiv ist er jedenfalls nicht.
Und auch der Kosten- und Zeitfaktor ist nicht zu unterschätzen: Vor allem, wenn es sich um mehr als ein 200-Zeilen-Hobby-Projekt handelt, fragt man sich zurecht, ob man sich die Mühe wirklich machen möchte, um rein theoretisch die neuen Python-3-Features nutzen zu können, die man aber bisher gar nicht vermisst hatte. Und wenn es um Anwendungen im gewerblichen Bereich geht, dann kommen wie gesagt noch die entsprechenden Kosten dazu. Vorgesetzte, die über die Verteilung des Budgets im Unternehmen entscheiden, neigen dazu, nur dann Geld zu bewilligen, wenn sie die Bearbeitung der Aufgabe als wirklich dringlich und für das Unternehmen förderlich einstufen. Und einem solchen Vorgesetzten soll mal erklärt werden, warum die Mitarbeiter gerade jetzt die nächsten Wochen mit einer Portierung verbringen sollen, wo doch erst kürzlich mitgeteilt wurde, dass die Supportzeit von Python 2.7 deutlich verlängert wird...
Um das klar zu sagen: Auch ich bin kein Gegner von Python 3, aber mit der Zeit ist mir deutlich bewusster geworden, dass eine Portierung in einigen Fällen nicht mal so eben gemacht ist, wie es der Autor des verlinkten Artikels darstellen will. Entweder fehlt ihm dieses Bewusstsein (noch) oder blendet diesen Faktor absichtlich von seiner Argumentation aus. Möglicherweise fällt es bei ihm ja auch in den Bereich "die Probleme der anderen sind nicht unsere Probleme". Dann frage ich mich aber, was der Artikel eigentlich bezwecken soll. Wirklich konstruktiv ist er jedenfalls nicht.
Python hat Ökonischen besetzt, in denen es zur Infrastruktur geworden ist. Schaut man sich z.B. mal die Downloadzahlen der Pakete rund um scientific python Pakete an, so geben diese ein anderes Bild ab als der Autor suggerieren möchte (liegen eher bei 8:1 für 2.x:3.x). Und da liegt imho der Hund begraben - Eingriffe in die Infrastruktur sind immer mit Verwerfungen verbunden und bedürfen starker Argumente, um sie durchzusetzen - positive in Form von Verbesserungen/Anreizen bzw. negative in Form von Macht/Gewalt.
Zu den "positiven" Argumenten - Verbesserungen/Anreize:
Hier war Python 3 zu Anfang sehr schwach aufgestellt und die aufgeführten Verbesserungen wollten nicht so recht überzeugen. Hierunter zähle ich mal Dinge wie "alles ist ein Iterator" und die geänderte Zeichenkettenbehandlung. Die Argumente schienen selbst die Entwickler nicht recht zu überzeugen und waren damals mit der Aussage verknüpft, dass Python 2 noch eine Weile koexistieren und mit Backports versehen wird. Während die Iteratorsache toll ist, mich aber unter Python 2 nichts davon abhält, die i* Varianten (izip, imap, etc.) jetzt schon zu nutzen (also keinen echten Mehrwert darstellt), ist die Zeichenkettenbehandlung zwar zunächst eine Vereinfachung, bricht aber mit vielen Sub-APIs, wie die Diskussion um WSGI zeigte. Hier kam mitunter der Eindruck einer "Verschlimmbesserung" auf.
Zu den "negativen" Argumenten - Macht/Gewalt:
Hierzu zähle das Ende des Supportzyklus, sowohl was Features (Backports) als auch Sicherheitsfixes angeht ("Kraft meiner Wassersuppe-Argumente"). Diesen Punkt hat der Autor des Rants auch gleich mit der Jeopardy-Melodie unterlegt - ich fand es witzig, kann aber aufgrund des Zwanges auch als Hohn ausgelegt werden. Warum Zwang? Imho ist sein Argument, Python zu forken, ein Scheinargument. Jeder, der in größere Projekte involviert ist, weiss, welche Verantwortung und Aufwand dies bedeutet. Diese Hürde ist so hoch gesteckt, dass keinem der Wald und Wiesen Verantwortlichen, welche auf Python infrastrukturkritisch gesetzt haben und nun mit 10k*x Zeilen inkompatiblen Code dasitzen, geholfen ist (ok, das war tendenziös
). Auch möchte keiner n Python 2-Klone haben, dafür braucht es eine entsprechende Organisationstruktur, die tonangebend ist (diese ist ja eigentlich schon vorhanden).
An dieser Stelle möchte ich den Ball gerne zurückspielen und fragen, ob sich die PSF überhaupt der Konsequenzen dieses Schrittes bewusst war. Infrastrukturänderungen brauchen starke Pro-Argumente, wenn diese dünn ausfallen, darf man sich nicht wundern, wenn sie nur zögerlich übernommen werden. Im Falle von Python mit dem batteries included-Ansatz (plus tollen Drittlibs) wiegt das besonders schwer. Alles was in dem Rant unter "The elephant in the room" gesagt wird, ist höchst problematisch - wenn das die offizielle Lesart sein soll, dann wird Python auf Hobby- und Spielplatzniveau zurückgestutzt werden, was die Verbreitung angeht. Dann muss man sich nicht wundern, wenn die Leute zu anderen Sprachen "überlaufen".
</rant>
Zu den "positiven" Argumenten - Verbesserungen/Anreize:
Hier war Python 3 zu Anfang sehr schwach aufgestellt und die aufgeführten Verbesserungen wollten nicht so recht überzeugen. Hierunter zähle ich mal Dinge wie "alles ist ein Iterator" und die geänderte Zeichenkettenbehandlung. Die Argumente schienen selbst die Entwickler nicht recht zu überzeugen und waren damals mit der Aussage verknüpft, dass Python 2 noch eine Weile koexistieren und mit Backports versehen wird. Während die Iteratorsache toll ist, mich aber unter Python 2 nichts davon abhält, die i* Varianten (izip, imap, etc.) jetzt schon zu nutzen (also keinen echten Mehrwert darstellt), ist die Zeichenkettenbehandlung zwar zunächst eine Vereinfachung, bricht aber mit vielen Sub-APIs, wie die Diskussion um WSGI zeigte. Hier kam mitunter der Eindruck einer "Verschlimmbesserung" auf.
Zu den "negativen" Argumenten - Macht/Gewalt:
Hierzu zähle das Ende des Supportzyklus, sowohl was Features (Backports) als auch Sicherheitsfixes angeht ("Kraft meiner Wassersuppe-Argumente"). Diesen Punkt hat der Autor des Rants auch gleich mit der Jeopardy-Melodie unterlegt - ich fand es witzig, kann aber aufgrund des Zwanges auch als Hohn ausgelegt werden. Warum Zwang? Imho ist sein Argument, Python zu forken, ein Scheinargument. Jeder, der in größere Projekte involviert ist, weiss, welche Verantwortung und Aufwand dies bedeutet. Diese Hürde ist so hoch gesteckt, dass keinem der Wald und Wiesen Verantwortlichen, welche auf Python infrastrukturkritisch gesetzt haben und nun mit 10k*x Zeilen inkompatiblen Code dasitzen, geholfen ist (ok, das war tendenziös
). Auch möchte keiner n Python 2-Klone haben, dafür braucht es eine entsprechende Organisationstruktur, die tonangebend ist (diese ist ja eigentlich schon vorhanden).An dieser Stelle möchte ich den Ball gerne zurückspielen und fragen, ob sich die PSF überhaupt der Konsequenzen dieses Schrittes bewusst war. Infrastrukturänderungen brauchen starke Pro-Argumente, wenn diese dünn ausfallen, darf man sich nicht wundern, wenn sie nur zögerlich übernommen werden. Im Falle von Python mit dem batteries included-Ansatz (plus tollen Drittlibs) wiegt das besonders schwer. Alles was in dem Rant unter "The elephant in the room" gesagt wird, ist höchst problematisch - wenn das die offizielle Lesart sein soll, dann wird Python auf Hobby- und Spielplatzniveau zurückgestutzt werden, was die Verbreitung angeht. Dann muss man sich nicht wundern, wenn die Leute zu anderen Sprachen "überlaufen".
</rant>
-
BlackJack
@snafu: Vollste Zustimmung!
@HorstJENS: Vielleicht noch als Erklärung: Ich habe in letzter Zeit mehrfach versucht das was snafu schreibt auf Google+ „Python 3-Fanatikern” zu erklären, und das sind sie da fast alle mit ziemlich religiösem Eifer, und habe neben einem Haufen Beleidigungen (faul und zu dumm war häufig dabei) daraufhin so praxistaugliche Tipps bekommen, wie „kündigen!”. Ich habe nette Kollegen und einen Job der mir Spass macht, finde Python toll, auch 2.x, und kann halt aus diversen praktischen und ökonomischen Gründen noch nicht auf Python 3 umsteigen, wobei mir bei 2.x nichts wirklich fehlt was Python 3 mitbringt. Da ist kündigen *die* Lösung… ernsthaft‽ m)
Eine Sache die mir am „Python 3 is fine”-Beitrag aufstösst ist zum Beispiel die „Gegenargumentation” dazu das Python 3 nichts bietet was einen den Sprung auch gegen etwas mehr Widerstand als bisherigen Versionswechseln machen lässt, weil auf der anderen Seite etwas cooles wartet. Bei den zig Seiten Changelogs mit der Spielshow-Melodie im Hintergrund mag sich der Autor ja superclever und cool und schnippisch fühlen, aber warum kann er da bei *so vielen Seiten* nicht einfach mal *konkret* etwas nennen? Das sollte doch nicht so schwer sein, möchte man denken. Allerdings muss man dann erst einmal alles aus den Seiten rausrechnen was Bibliotheken angeht (da gibt's Backports für Python 2.7), und vielleicht fairerweise auch die ganzen Bugfixes Unicode betreffend die da nur drinstehen weil sie durch die Umstellung erst entstanden sind. Dann bleiben letztlich nur Sprachänderungen die nicht als Bibliothek rückportierbar sind. Und mich reisst da echt nichts vom Hocker. Oder habe ich irgend etwas übersehen?
Wenn ich bei G+ gefragt habe was denn den Kosten einer Portierung gegenüber steht; also welchen Vorteil ich damit gewinne wenn ich *jetzt* portiere; was mir Python 3 bringt, kamen immer nur zwei ”Argumente”: „Python 2.7 is deprecated” und „Python 3 is the future”. Mantraartig, so dass man mit der übrigen beleidigenden und feindseligen Art fast den Eindruck gewinnen konnte, dass da Verzweiflung mit im Spiel ist.
@HorstJENS: Vielleicht noch als Erklärung: Ich habe in letzter Zeit mehrfach versucht das was snafu schreibt auf Google+ „Python 3-Fanatikern” zu erklären, und das sind sie da fast alle mit ziemlich religiösem Eifer, und habe neben einem Haufen Beleidigungen (faul und zu dumm war häufig dabei) daraufhin so praxistaugliche Tipps bekommen, wie „kündigen!”. Ich habe nette Kollegen und einen Job der mir Spass macht, finde Python toll, auch 2.x, und kann halt aus diversen praktischen und ökonomischen Gründen noch nicht auf Python 3 umsteigen, wobei mir bei 2.x nichts wirklich fehlt was Python 3 mitbringt. Da ist kündigen *die* Lösung… ernsthaft‽ m)
Eine Sache die mir am „Python 3 is fine”-Beitrag aufstösst ist zum Beispiel die „Gegenargumentation” dazu das Python 3 nichts bietet was einen den Sprung auch gegen etwas mehr Widerstand als bisherigen Versionswechseln machen lässt, weil auf der anderen Seite etwas cooles wartet. Bei den zig Seiten Changelogs mit der Spielshow-Melodie im Hintergrund mag sich der Autor ja superclever und cool und schnippisch fühlen, aber warum kann er da bei *so vielen Seiten* nicht einfach mal *konkret* etwas nennen? Das sollte doch nicht so schwer sein, möchte man denken. Allerdings muss man dann erst einmal alles aus den Seiten rausrechnen was Bibliotheken angeht (da gibt's Backports für Python 2.7), und vielleicht fairerweise auch die ganzen Bugfixes Unicode betreffend die da nur drinstehen weil sie durch die Umstellung erst entstanden sind. Dann bleiben letztlich nur Sprachänderungen die nicht als Bibliothek rückportierbar sind. Und mich reisst da echt nichts vom Hocker. Oder habe ich irgend etwas übersehen?
Wenn ich bei G+ gefragt habe was denn den Kosten einer Portierung gegenüber steht; also welchen Vorteil ich damit gewinne wenn ich *jetzt* portiere; was mir Python 3 bringt, kamen immer nur zwei ”Argumente”: „Python 2.7 is deprecated” und „Python 3 is the future”. Mantraartig, so dass man mit der übrigen beleidigenden und feindseligen Art fast den Eindruck gewinnen konnte, dass da Verzweiflung mit im Spiel ist.
Ich denke, viele private und unternehmensinterne Projekte werden für die nächste Zeit einfach bei Python 2.7 stehen bleiben - auch noch in 4-5 Jahren. Für neue Projekte oder Unterprojekte bzw neue Komponenten von Systemlandschaften sollte man sich IMHO zwischen zwei Möglichkeiten entscheiden:
I.) Weiterhin Python. Dann aber sinnigerweise Python 3.x, weil man in dem neuen Projekt ja abgesehen von spezifischen Zielvorgaben wieder bei Null anfangen kann. Falls das Anschmeißen von zwei nebeneinander laufenden Interpretern (2.7 vs 3.x) nicht gewollt oder möglich ist (z.B. bei Modul-Importen), dann muss man halt abwärtskompatiblen 3.x-Code als Krücke nehmen. Das wäre meiner Meinung nach ein noch vertretbarer Mehraufwand, der zumindest neue Module tauglich für die Post-2.7-Ära macht. Und wenn's irgendwann fünf vor zwölf ist - also z.B. weil die Sicherheitsbedenken einfach zu groß werden -, dann würde man "nur" noch die verbliebenen reinen 2.7-Bestandteile neu schreiben müssen.
II.) Wechsel auf eine andere Sprache wie z.B. Ruby - wie gesagt: Erstmal für neue Projekte. Hat allerdings den Nachteil, dass man am Support-Ende von Python möglicherweise sehr viel Code auf einmal portieren muss - je nach Abhängigkeiten, anstatt suksessive einzelne Python-Module 3.x-tauglich zu machen. Gut, man kann Python-Module, die bisher Interpreter-intern kommuniziert haben, mit einer von Python unabhängigen Schnittstelle versehen. Nur wäre das reichlich umständlich und an sich auch eine Ressourcenverschwendung, weil das Python-2.7-Modul ja eh irgendwann sterben müsste. Auch finde ich es schon praktischer, in einer von Python dominierten Systemlandschaft auch entsprechend Python-Module im Interpreter benutzen zu können, anstatt CLI- oder Socket-Lösungen für die Interprozesskommunikation zu bemühen.
Aber gut, was schwafel ich hier groß herum: *Ich* muss sowas ja ohnehin nicht entscheiden.
I.) Weiterhin Python. Dann aber sinnigerweise Python 3.x, weil man in dem neuen Projekt ja abgesehen von spezifischen Zielvorgaben wieder bei Null anfangen kann. Falls das Anschmeißen von zwei nebeneinander laufenden Interpretern (2.7 vs 3.x) nicht gewollt oder möglich ist (z.B. bei Modul-Importen), dann muss man halt abwärtskompatiblen 3.x-Code als Krücke nehmen. Das wäre meiner Meinung nach ein noch vertretbarer Mehraufwand, der zumindest neue Module tauglich für die Post-2.7-Ära macht. Und wenn's irgendwann fünf vor zwölf ist - also z.B. weil die Sicherheitsbedenken einfach zu groß werden -, dann würde man "nur" noch die verbliebenen reinen 2.7-Bestandteile neu schreiben müssen.
II.) Wechsel auf eine andere Sprache wie z.B. Ruby - wie gesagt: Erstmal für neue Projekte. Hat allerdings den Nachteil, dass man am Support-Ende von Python möglicherweise sehr viel Code auf einmal portieren muss - je nach Abhängigkeiten, anstatt suksessive einzelne Python-Module 3.x-tauglich zu machen. Gut, man kann Python-Module, die bisher Interpreter-intern kommuniziert haben, mit einer von Python unabhängigen Schnittstelle versehen. Nur wäre das reichlich umständlich und an sich auch eine Ressourcenverschwendung, weil das Python-2.7-Modul ja eh irgendwann sterben müsste. Auch finde ich es schon praktischer, in einer von Python dominierten Systemlandschaft auch entsprechend Python-Module im Interpreter benutzen zu können, anstatt CLI- oder Socket-Lösungen für die Interprozesskommunikation zu bemühen.
Aber gut, was schwafel ich hier groß herum: *Ich* muss sowas ja ohnehin nicht entscheiden.
Zuletzt geändert von snafu am Sonntag 1. Juni 2014, 16:07, insgesamt 1-mal geändert.
-
HorstJENS
- User
- Beiträge: 123
- Registriert: Donnerstag 9. Februar 2006, 21:41
- Wohnort: Wien, Österreich
- Kontaktdaten:
ohne Eure Diskussion stören zu wollen:
Meine ursprüngliche Frage war ob mir jemand meine Übersetzung (cc-by-sa lizensiert) Korrektur liest. Ich freue mich auch über Übersetzung anderer Postings zum Thema ins Deutsche bzw gute Gegenartikel. Mir ist weniger wichtig ob der Artikel für oder gegen Python3 / 2 argumentiert, mir ist wichtig ob ich den Artikel cc-by-sa lizensiert in meiner Zeitschrift abdrucken kann. (Die ganze Zeitschrift ist cc-by-sa lizensiert). Das Thema worum es in mir und der Zeitschrift geht ist der "Share" free/libre open source Gedanke, und deshalb habe ich den "python3 is fine" Artikel übersetzt weil er meiner Meinung nach gut zeigt dass es nichts bringt an einen Haufen unbezahlter, freiwilliger Entwickler mit Forderungen heranzutreten, sondern dass man entweder selber entwickeln oder jemanden dafür bezahlen sollte.
Ich interpretiere Eure bisherigen Postings als "Nein" und schaue mich derweil woanders nach cc-by-sa lizensierten republizierbaren Artikeln um.
Meine ursprüngliche Frage war ob mir jemand meine Übersetzung (cc-by-sa lizensiert) Korrektur liest. Ich freue mich auch über Übersetzung anderer Postings zum Thema ins Deutsche bzw gute Gegenartikel. Mir ist weniger wichtig ob der Artikel für oder gegen Python3 / 2 argumentiert, mir ist wichtig ob ich den Artikel cc-by-sa lizensiert in meiner Zeitschrift abdrucken kann. (Die ganze Zeitschrift ist cc-by-sa lizensiert). Das Thema worum es in mir und der Zeitschrift geht ist der "Share" free/libre open source Gedanke, und deshalb habe ich den "python3 is fine" Artikel übersetzt weil er meiner Meinung nach gut zeigt dass es nichts bringt an einen Haufen unbezahlter, freiwilliger Entwickler mit Forderungen heranzutreten, sondern dass man entweder selber entwickeln oder jemanden dafür bezahlen sollte.
Ich interpretiere Eure bisherigen Postings als "Nein" und schaue mich derweil woanders nach cc-by-sa lizensierten republizierbaren Artikeln um.
http://spielend-programmieren.at