Wer von Euch benutzt eigentlich Python3?
Manchmal.
MorgenGrauen: 1 Welt, 8 Rassen, 13 Gilden, >250 Abenteuer, >5000 Waffen & Rüstungen,
>7000 NPC, >16000 Räume, >200 freiwillige Programmierer, nur Text, viel Spaß, seit 1992.
>7000 NPC, >16000 Räume, >200 freiwillige Programmierer, nur Text, viel Spaß, seit 1992.
Wenn es sein muss benutze ich Python3, z.B. ist in Blender Python3 eingebaut.
Ich sehe das dann aber nicht als Vorteil, sondern als ein Stück Extra-Arbeit, Python3 gibt mir keine Vorteile, lediglich die Arbeit, mich mit noch einem Python beschäftigen zu müssen.
Warum ist das so? Bei Java sind alle froh, wenn sie auf die nächste Version umsteigen können, wieder etwas mehr Funktionalität in der Sprache selbst enthalten, die es vorher nur über externe Tools gab. Entwickelt man Intranetanwendungen, dann ist man froh, wenn der unternehmensweit eingesetzte Browser eine möglichst hohe Version hat, weil dann die aktuellen Tools für Webanwendungen genutzt werden können. Qt4 Code ist einfacher als Qt3 Code. Dagegen ist der Umstieg auf Python3 etwa so populär wie der Umstieg auf Windows8 .
Ich sehe das dann aber nicht als Vorteil, sondern als ein Stück Extra-Arbeit, Python3 gibt mir keine Vorteile, lediglich die Arbeit, mich mit noch einem Python beschäftigen zu müssen.
Warum ist das so? Bei Java sind alle froh, wenn sie auf die nächste Version umsteigen können, wieder etwas mehr Funktionalität in der Sprache selbst enthalten, die es vorher nur über externe Tools gab. Entwickelt man Intranetanwendungen, dann ist man froh, wenn der unternehmensweit eingesetzte Browser eine möglichst hohe Version hat, weil dann die aktuellen Tools für Webanwendungen genutzt werden können. Qt4 Code ist einfacher als Qt3 Code. Dagegen ist der Umstieg auf Python3 etwa so populär wie der Umstieg auf Windows8 .
Ich schreib Code der unter Python 2 und Python 3 läuft. Wenn ich allerdings ehrlich bin sehe ich momentan was Python an geht keine gute Zukunft. Javascript (bzw. ECMAScript 2015) wird schneller besser daran Python zu ersetzen, als Python die Verluste im gegenüber Javascript wett machen kann und während Javascript Python in der horizontalen angreift, greifen Sprachen wie Go und Rust von unten an.
Ich glaube wir werden in 10 Jahren auf Python 3 als den Anfang vom Ende Pythons zurückblicken.
Ich glaube wir werden in 10 Jahren auf Python 3 als den Anfang vom Ende Pythons zurückblicken.
Hmm Zukunftsangst um Python - ja. Python hat sich nur ein starkes Biotop mit scientific calculation geschaffen. In anderen für Python typischen Bereichen (server scripting, Desktophelferlein bei einigen Linuxdistributionen, Webapps) führt es in der Gesamtschau eher ein Nischendasein. Javascript schickt sich an, mit ECMA6 eine halbwegs brauchbare Sprache ohne Hirnkrämpfe zu werden, ist mit Node längst auf dem Server angekommen und zieht jetzt wohl auf dem Desktop nach. Die schiere Auswahl an community driven node packages ist überwältigend wenn man bedenkt, in welch kurzer Zeit das alles entstanden ist (leider zulasten der Codequalität, die häufig unterirdisch ist). Längerfristig traue ich Javascript sogar zu, die Java-Enterprisewelt unter Beschuss zu nehmen. Was den Angriff von unten angeht, da könnte man evtl. Swift noch mit aufführen, je nachdem, wie Apple das letztendlich lizensieren wird.
Ich nutze Python und hoffe mal, dass die Sprache eine lange Zukunft hat (v. a. scientific calculation). Vorschläge, was man tun kann, um Python dauerhaft gegenüber anderen Sprachen besser zu positionieren!?
Python 3 ist ein schönes Beispiel dafür, welche krassen Langzeitfolgen das Brechen von Abwärtskompatibilität in einem populären Produkt haben kann. Dazu kommen dann noch die anfänglichen Probleme, insbesondere in Python 3.0. Man kann ja keinesfalls behaupten, dass der Python-3-Zweig eingeschlafen wäre. Auch sind reichlich Bibliotheken inzwischen fit für Python 3 gemacht worden. Nur irgendwie scheint trotzdem kaum jemand die "neue" Version freiwillig nutzen zu wollen.
Python 3 wird von vielen leider eher als Ballast anstatt als nützlich angesehen. Meiner Meinung nach stecken da neben den durchaus nachvollziehbaren Gründen hinsichtlich der teils aufwändigen Portierungsarbeiten auch ein stückweit ideologische Gründe dahinter. Und wenn die Community im Großen und Ganzen keine Lust auf Python 3 hat, dann wird es halt wirklich schwierig, was die Zukunft von Python insgesamt angeht. Aber gut, noch wollen wir Python nicht begraben. Dafür ist insbesondere Python 2.7 noch zu beliebt. Vielleicht braucht es tatsächlich ein Python 4, das fachlich und ggf auch unterstützt durch gute PR überzeugen kann, sodass die Beurteilungen über den Weg, den Python einschlägt, wieder etwas positiver ausfallen.
Python 3 wird von vielen leider eher als Ballast anstatt als nützlich angesehen. Meiner Meinung nach stecken da neben den durchaus nachvollziehbaren Gründen hinsichtlich der teils aufwändigen Portierungsarbeiten auch ein stückweit ideologische Gründe dahinter. Und wenn die Community im Großen und Ganzen keine Lust auf Python 3 hat, dann wird es halt wirklich schwierig, was die Zukunft von Python insgesamt angeht. Aber gut, noch wollen wir Python nicht begraben. Dafür ist insbesondere Python 2.7 noch zu beliebt. Vielleicht braucht es tatsächlich ein Python 4, das fachlich und ggf auch unterstützt durch gute PR überzeugen kann, sodass die Beurteilungen über den Weg, den Python einschlägt, wieder etwas positiver ausfallen.
Hinsichtlich der aufkommenden konkurrierenden Alternativen zu Python in vielen Bereichen: Das ist jetzt etwas, das wahrscheinlich auch ohne die schiefgelaufene Einführung von Python 3 passiert wäre. Pythons großes Manko ist bekanntlich seine mäßige Geschwindigkeit, die leider dann auffällt, wenn Performance wichtig wird. Meiner Meinung nach müsste man hier einfach mal den Hintern hochkriegen und anfangen, PyPy-Features in Python zu integrieren.
Das wäre z.B. ein gutes Thema und Highlight für ein mögliches Python 4. Vielleicht wird Python ja dadurch wichtiger für die Web-Entwicklung, für Server, usw. - wer weiß das schon. Guido baut ja momentan einiges an asynchronen Features in Python ein. Auch dies könnte auf dem Weg zu einer Sprache, die gut für die Web-Entwicklung geeignet ist, hilfreich sein.
Auf jeden Fall muss Python klare Konzepte für die mittelfristige Weiterentwicklung finden. Sicherlich gibt es die schon, sowohl die PEPs als auch bestimmt durch interne Besprechungen, sowie öffentlich auf der Mailing-List. Aber das alles muss IMHO noch viel mehr nach außen getragen werden. Der (potenzielle) Nutzer muss sehen können, warum er gerade Python und eben nicht JavaScript oder ähnliches für seine Vorhaben nutzen soll. Natürlich gibt es die Success Stories. Aber leider sind die doch recht umfangreich und man erfährt auch nicht so wirklich, wie genau ein Vorhaben denn nun umgesetzt wurde. Das ist mir alles noch viel zu oberflächlich.
Das wäre z.B. ein gutes Thema und Highlight für ein mögliches Python 4. Vielleicht wird Python ja dadurch wichtiger für die Web-Entwicklung, für Server, usw. - wer weiß das schon. Guido baut ja momentan einiges an asynchronen Features in Python ein. Auch dies könnte auf dem Weg zu einer Sprache, die gut für die Web-Entwicklung geeignet ist, hilfreich sein.
Auf jeden Fall muss Python klare Konzepte für die mittelfristige Weiterentwicklung finden. Sicherlich gibt es die schon, sowohl die PEPs als auch bestimmt durch interne Besprechungen, sowie öffentlich auf der Mailing-List. Aber das alles muss IMHO noch viel mehr nach außen getragen werden. Der (potenzielle) Nutzer muss sehen können, warum er gerade Python und eben nicht JavaScript oder ähnliches für seine Vorhaben nutzen soll. Natürlich gibt es die Success Stories. Aber leider sind die doch recht umfangreich und man erfährt auch nicht so wirklich, wie genau ein Vorhaben denn nun umgesetzt wurde. Das ist mir alles noch viel zu oberflächlich.
Wobei ich mir hier auch Dekoratoren vorstellen könnte, mit denen man optional die Typen von Parametern und/oder Rückgabewerten beim Definieren von Callables angeben kann.jerch hat geschrieben:- optionale Typenangabe
Bei performancekritischen Funktionen wäre es auch nett, wenn man das schöne Duck-Typing einfach mal ausschalten könnte, sodass der Interpreter einen `int` wirklich wie ein Primitive behandeln kann und damit den ganzen Overhead, den die Behandlung "echter" Objekte so mit sich bringt, fallen lassen kann.
Aber das wäre natürlich schon ein sehr krasser Eingriff in die Paradigmen von Python und sicherlich auch nicht trivial zu implementieren. Da müsste man schon sehen, wie man das sinnvoll umsetzen kann und ob die Community das überhaupt will.
-
BlackJack
@snafu: Das mit dem ”ausschalten” vom Duck Typing kannst Du doch jetzt schon haben, entweder mit PyPy implizit und ”on the fly” oder mit Cython explizit mit einem Kompilationsschritt.
@meego: Das mit dem `print()` ist aber eher kosmetisch und IMHO auch eine ganz gute Idee dafür keine Sonderstellung in Form eines Schlüsselworts zu haben. Das sollte auch das geringste Problem beim portieren machen, denn das lässt sich automatisiert umschreiben und das Werkzeug dafür bekommt man bei aktuellen Python-Versionen schon frei Haus mitgeliefert. Die Änderung lässt sich auch in Python 2.7 schon per `__future__`-Import aktivieren, da gibt es also auch die Möglichkeit eines sanften Übergangs.
Die Vorteile von `print()` sind neben der weggefallenen syntaktischen Sonderstellung, dass man die Funktion durch eine eigene ersetzen kann und das man die Funktion als Argument übergeben kann oder als Wert in Datenstrukturen speichern kann.
@meego: Das mit dem `print()` ist aber eher kosmetisch und IMHO auch eine ganz gute Idee dafür keine Sonderstellung in Form eines Schlüsselworts zu haben. Das sollte auch das geringste Problem beim portieren machen, denn das lässt sich automatisiert umschreiben und das Werkzeug dafür bekommt man bei aktuellen Python-Versionen schon frei Haus mitgeliefert. Die Änderung lässt sich auch in Python 2.7 schon per `__future__`-Import aktivieren, da gibt es also auch die Möglichkeit eines sanften Übergangs.
Die Vorteile von `print()` sind neben der weggefallenen syntaktischen Sonderstellung, dass man die Funktion durch eine eigene ersetzen kann und das man die Funktion als Argument übergeben kann oder als Wert in Datenstrukturen speichern kann.
Meh. Die ganzen "Python" Compiler die es schon gibt sind alle Mist und dass liegt nicht primär am Backend.jerch hat geschrieben:Python 4:
- mit Frontend für LLVM
Gibts es schon bzw. kommt mit Python 3.5 noch dieses Jahr.- optionale Typenangabe
PyPy ist gerade dabei STM zu bauen um den GIL mit Transactions zu ersetzen (lies: GIL wird eliminiert). Ist zwar noch immer in einem separaten Branch aber das Projekt scheint aber schon lange kein Experiment zu sein und es ist wohl nur noch eine Frage von "wann" und nicht "ob".- kein GIL
Klar, aber es wäre schön, wenn das "Standard-Python" dies auch könnte. Natürlich besteht hier immer die Gefahr, dass man es etwas übertreibt mit den compilerseitigen Features und die Sprache damit unnötig aufbläht oder sie - wie schon angesprochen - in eine unschöne Richtung treibt. Zumal man keine Kontrolle darüber hat, wer welches Feature wie nutzt. Andererseits würden viele Benutzer gewisse Features im Prinzip gar nicht benötigen, sodass ein Anfänger-Tutorial z.B. die Themen, die mit Typsicherheit (oder besser gesagt: optionaler statischer Typisierung) zu tun haben, komplett aussparen könnte. Somit fände man gewisse Features wahrscheinlich nur in speziell optimiertem Code bestimmter Bibliotheken wieder und die potenziellen Performance-Vorteile wären so für "jedermann" nutzbar, ohne dass man direkten Kontakt zu übermäßig komplizierten Konstrukten hat. Bisher geht das eben nur mittels C-Code oder mit Cython-Code oder durch die Nutzung von PyPy.BlackJack hat geschrieben:@snafu: Das mit dem ”ausschalten” vom Duck Typing kannst Du doch jetzt schon haben, entweder mit PyPy implizit und ”on the fly” oder mit Cython explizit mit einem Kompilationsschritt.
-
BlackJack
@meego: Also wenn eine Klammer eingeben schon Fingerverrenkung ist, dann ist Programmieren nichts für Dich oder Du hast ein komisches Tastaturlayout. Für Debugausgaben verwende ich gerne das `q`-Modul. Oder gleich vernünftiges Logging, da muss man dann sowieso Klammern eingeben.
Kleiner Tipp: Tastaturen mit US Layout nutzen,da wird einem auch so einiges klarer was so manche Entscheidungen bezüglich der Syntax von Programmiersprachen angeht.meego hat geschrieben:@blackjack: Für mich bedeutete es einfach mehr Fingerverrenkung beim Fehlertest.