Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
jerch hat geschrieben:Python 4:
- mit Frontend für LLVM
Meh. Die ganzen "Python" Compiler die es schon gibt sind alle Mist und dass liegt nicht primär am Backend.
- optionale Typenangabe
Gibts es schon bzw. kommt mit Python 3.5 noch dieses Jahr.
- kein GIL
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".
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.
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.
@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.
meego hat geschrieben:@blackjack: Für mich bedeutete es einfach mehr Fingerverrenkung beim Fehlertest.
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.
@DasIch: Wobei sich das bei den runden Klammern für einen Funktionsaufruf jetzt nicht viel nimmt. Die eckigen und geschweiften Klammern sind da ja eher ein Unterschied.
@meego: Vernünftigen Editor verwenden den man so konfigurieren kann das er die schliessende Klammer automatisch einfügt, und schon hat man sich eine ”Verrenkung” gespart. Oder gleich ein `print`-Makro das auch die Klammern schon enthält.
BlackJack hat geschrieben:@DasIch: Wobei sich das bei den runden Klammern für einen Funktionsaufruf jetzt nicht viel nimmt. Die eckigen und geschweiften Klammern sind da ja eher ein Unterschied.
Stimmt aber ;, /, \, ', ", < und > sind alle ebenfalls leichter zu tippen sofern ich mich richtig an das deutsche Layout erinnere.
Also ich starte alle neuen Projekte in py3 und mache sie evtl im nachhinein zu py2 kompatibel...
Mir fehlt keine lib mehr,die es nur für py2 gibt.
Sehe auch nicht, das Python an Popularität verlieren würde. Ehe im Gegenteil: scheint es doch im Bildungsbereich mehr und mehr eingesetzt zu werden....
Super Vorteile hat py3 nicht. Aber viele kleine, die in der Summe schon überwiegen...
Prrfomance sehe ich nicht als den kanackpunkt an. Man könnte auch rpython nehmen.
jens hat geschrieben:Prrfomance sehe ich nicht als den kanackpunkt an. Man könnte auch rpython nehmen.
RPython kann man für vieles nehmen aber nicht wenn man einfach mehr Performance haben will. Wenn man nicht darauf achtet seinen Python Code RPython zu halten ist er es höchstwahrscheinlich nicht. Man muss auf die stdlib (fast?) komplett verzichten, print und open stehen nicht zu Verfügung. Bei einigen Exceptions wie z.B. IndexError nimmt der Compiler an dass sie nicht auftreten können um Optimierungen ausführen zu können, wenn man sie nicht abfängt, was sich zur Laufzeit mit segfaults bemerkbar macht. Dazu kommt dass der Compiler ewig braucht um Code zu kompilieren, schon ein Hello World kann schon mal gut eine Minute dauern und dass ist nicht einfach konstanter Overhead. Hat der Code Fehler kann es schonmal gut sein dass der Compiler in einer Endlosschleife stecken bleibt und passiert dies nicht bekommt man einen Traceback und wird in eine pdb session geworfen. Nach zig Transformationsschritten, Generierung von C Code und Kompilierung von letzterem hat man dann auch irgendwann eine Binary die sich nur mit sehr großem Aufwand debuggen lässt, selbst wenn man wollte könnte man Obfuscation nur schwer ähnlich gut hinbekommen.
RPython hat durchaus seine Berechtigung aber es erfordert schon einiges an Motivation und eine gute Dosis Masochismus, wenn man es benutzen will.
Seit knapp sechs Jahren fast nur noch Python 3, einzige Ausnahme: meine Dabo-Anwendungen. Ich würde die gern auf PyQt umschreiben, aber mit der Kombination Datenbank + PyQt komme ich leider ganz schlecht zurecht.
Weil das schon so lange her ist, kann ich den ewigen Ärger mit dem Weiterverarbeiten von Datenbankausgaben in Python 2 nicht mehr richtig darstellen, aber den los zu sein war das bisschen Umstellung allemal wert. Allerdings programmiere ich für den Eigenbedarf und nicht für Dritte, das erleichtert jeden Wechsel gewaltig.
Auf meinem Mac bin ich so ziemlich glücklich mit Python 3.4. Habe mir Anaconda3 heruntergeladen, das kommt mit allen notwendigen wissenschaftlichen Modulen, und dazu noch kostenlos! Das IPython Notebook ist auch ganz toll. Python3 handiert Unicode viel besser als Python2.
Oder gleich ein `print`-Makro das auch die Klammern schon enthält.
