| View previous topic :: View next topic |
| Author |
Message |
flammenflitzer
Advocate
Joined: 25 Nov 2003
Posts: 3479
Location: Berlin
|
 Posted: Thu Dec 26, 2013 4:38 pm Post subject: python Version |
 |
|
Hallo,
| Code: | eselect python list
Available Python interpreters:
[1] python2.7
[2] python3.2 *
[3] python3.3 |
Was sollte man da setzten? Ich habe aktuell 3.2. Jetzt ist 3.3 stabil in portage. Viele Programme scheinen 2.7 zu bevorzugen. |
|
| Back to top |
|
 |
Jean-Paul
Guru
Joined: 13 Apr 2009
Posts: 307
|
| Posted: Fri Dec 27, 2013 9:51 pm Post subject: |
|
|
Hi,
| Quote: | eselect python list
Available Python interpreters:
[1] python2.7 *
[2] python3.3 |
Python-3.2 hab ich gar nicht mehr, wurde imho mit Python-3.3 entfernt.
_________________
”Everything should be made as simple as possible, but no simpler.” – Albert Einstein |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sat Dec 28, 2013 10:12 am Post subject: |
|
|
| Wenn Du nicht selbst in Python enwickelst, würde ich >=python-3 maskieren: Es gibt fast nichts, was >python-2.7 braucht, aber umgekehrt laufen viele Sachen nicht mit python-3* und werden es wohl auch nie tun. |
|
| Back to top |
|
|
ulenrich
Veteran
Joined: 10 Oct 2010
Posts: 1480
|
| Posted: Sat Dec 28, 2013 11:34 am Post subject: |
|
|
| Code: | # equery h python_single_target_python3_3
* Searching for USE flag python_single_target_python3_3 ...
[IP-] [ ] kde-base/kate-4.12.0:4
[IP-] [ ] media-gfx/hugin-2013.0.0-r1:0
[IP-] [ ] net-misc/youtube-dl-2013.12.20:0
[IP-] [ ] sys-apps/util-linux-2.24:0
[IP-] [ ] x11-libs/libxcb-1.9.3:0 |
Alle ebuilds tauchen auch auf, wenn
# equery h python_single_target_python2_7
@mv , wenn man sehr viel mit emerge von portage hantiert, ist python3 nicht ein klitze-wenig schneller? Wieso taucht portage eigentlich nicht in der Liste auf? |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sat Dec 28, 2013 2:02 pm Post subject: |
|
|
| Quote: | | ist python3 nicht ein klitze-wenig schneller? |
Es gab mal einen Thread hier mit verschiedenen Benchmarks. Manche hatten mit pypy enorme Geschwindigkeitsvorteile, bei anderen ging es deutlich langsamer - hängt wohl i.W. vom RAM ab. Beim "offiziellen" Python-Interpreter würde ich keine großen Geschwindigkeitsunterschiede erwarten, aber ich habe python3 seit jeher maskiert, also keinen wirklichen Zeitvergleich. |
|
| Back to top |
|
|
ulenrich
Veteran
Joined: 10 Oct 2010
Posts: 1480
|
| Posted: Sat Dec 28, 2013 5:52 pm Post subject: |
|
|
| mv wrote: | | Quote: | | ist python3 nicht ein klitze-wenig schneller? |
Es gab mal einen Thread hier mit verschiedenen Benchmarks. Manche hatten mit pypy enorme Geschwindigkeitsvorteile, bei anderen ging es deutlich langsamer - hängt wohl i.W. vom RAM ab. Beim "offiziellen" Python-Interpreter würde ich keine großen Geschwindigkeitsunterschiede erwarten, aber ich habe python3 seit jeher maskiert, also keinen wirklichen Zeitvergleich. |
Pypy is für mich wohl ausser Frage:
mit meinen mikrigen 4 Gbyte Ram lässte es sich vermutlich gar nicht compilieren. Ausserdem ist die Zeitersparnis weg, wenn man dafür diese virtuelle Maschine eine Woche lang backen muss 
Python3 fühlt sich ein (klitze-klein) wenig schneller an mit Portages emerge. Die Erklärung dafür war im englischen Forum, wenn ich richtig erinnere, dass es im Gegensatz zu Python2 Klassen hat und daher ein besseres Caching der Funktionen. Wenn man nur Gentoo+stable alle paar Wochen updaten will, wird die wenig bessere Performance ncht ins Gewicht fallen!
PS: Ich merke gerade auf meiner experimentellen Gnome-3.10 Partition:
!! The ebuild selected to satisfy "media-sound/gnome-music" has unmet requirements.
- media-sound/gnome-music-3.10.1::gentoo USE="" PYTHON_SINGLE_TARGET="-python3_2 -python3_3"
Da ist dann doch nichts mehr möglich mit Python2. Ich habe das vorhin auch nicht gewusst, weil ich ein alter Kdeler bin ... |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sat Dec 28, 2013 6:56 pm Post subject: |
|
|
| Quote: | mit meinen mikrigen 4 Gbyte Ram[/quote9
Bei mir sind es 1 GB auf der kleinen, 2 GB auf der großen Maschine und 512 MB auf dem Laptop...
[quote="ulenrich"]Python3 fühlt sich ein (klitze-klein) wenig schneller an mit Portages emerge. |
"Fühlt sich an". Hast Du Benchmarks?
Als ich vor ewigen Zeiten mal Portage mit Python3 probiert habe, hatte ich nur schlechte Ausgaben bem wget und die Information, dass das in Python3 nicht geändert werden soll, daher war es nicht attraktiv. Das war damals allerdings noch python3.1 oder so; vielleicht wurde es entgegen der Ankündigung doch gefixt.
| Quote: | | dass es im Gegensatz zu Python2 Klassen hat |
Wie meinen? Python2 hat freilich Klassen. Du meinst vermutlich irgendeine bestimmte Klasse, die speziell von Portage genutzt wird!?
| Quote: | | PYTHON_SINGLE_TARGET="-python3_2 -python3_3" |
Klar, wenn man ein solches Projekt braucht, dann braucht man halt pyton3. Mich hat es aber sehr gewundert, dass es sehr wenige solche Projekte gibt, zumal der offizielle Ratschlag des Python-Autors war, nicht auf Abwärtskompatibilität zu achten. Einer der klassischen Unterschiede zwischen Theorie und Praxis. Bei meinem einzigen Python-Spielzeug-Projekt war auch die einzige notwendige Änderung die print()-Syntax, die leider bewusst inkompatibel gehalten wurde (ansonsten würden wahrscheinlich 90% der python2-Projekte unverändert mit python3 laufen). M.E. war dieser bewusste Kompatibilitätsbruch eine schlechte Idee, aber das braucht man jetzt nicht mehr zu disktutieren. |
|
| Back to top |
|
|
ulenrich
Veteran
Joined: 10 Oct 2010
Posts: 1480
|
| Posted: Sun Dec 29, 2013 12:51 am Post subject: |
|
|
| mv wrote: | | ulenrich wrote: | | Python3 fühlt sich ein (klitze-klein) wenig schneller an mit Portages emerge. |
"Fühlt sich an". Hast Du Benchmarks?
Als ich vor ewigen Zeiten mal Portage mit Python3 probiert habe, hatte ich nur schlechte Ausgaben bem wget und die Information, dass das in Python3 nicht geändert werden soll, daher war es nicht attraktiv. Das war damals allerdings noch python3.1 oder so; vielleicht wurde es entgegen der Ankündigung doch gefixt. |
Python-3.1 war auch nie Gentoo-stable. Das ist schon ein Zeichen, dass es nicht möglich war! Wegen der Performance habe ich nochmal nachgeschaut: Es ist die verbesserte dictionary Verwaltung mit python-3.3, was emerge sehr nützlich ist. Ist zwar nur 20% weniger Ram, der dadurch besser genutzt wird, aber das ist schon ein Betrag, der die Effektivität des Caching dann berührt.
| Quote: | | Quote: | | PYTHON_SINGLE_TARGET="-python3_2 -python3_3" |
Klar, wenn man ein solches Projekt braucht, dann braucht man halt pyton3. Mich hat es aber sehr gewundert, dass es sehr wenige solche Projekte gibt, zumal der offizielle Ratschlag des Python-Autors war, nicht auf Abwärtskompatibilität zu achten. Einer der klassischen Unterschiede zwischen Theorie und Praxis. Bei meinem einzigen Python-Spielzeug-Projekt war auch die einzige notwendige Änderung die print()-Syntax, die leider bewusst inkompatibel gehalten wurde (ansonsten würden wahrscheinlich 90% der python2-Projekte unverändert mit python3 laufen). M.E. war dieser bewusste Kompatibilitätsbruch eine schlechte Idee, aber das braucht man jetzt nicht mehr zu disktutieren. |
Hey, wenn Du als Publikum nur System-Administratoren hast, deren Englisch eine Berufsvoraussetzung ist, hast Du natürlich Recht. Aber erklär mal einem Asiaten, dass er erst Englisch lernen muss um seine Variablen benennen zu können  Im Ernst, die String Behandlung in Python-2 ist ein solches Durcheinander, voller Workarounds und kompliziert, dass es kaum zu erklären ist. Ich bin froh über einen klaren Schlusstrich. |
|
| Back to top |
|
|
flammenflitzer
Advocate
Joined: 25 Nov 2003
Posts: 3479
Location: Berlin
|
| Posted: Sun Dec 29, 2013 2:09 pm Post subject: |
|
|
So wie ich das verstehe:
Python interpreter auf python2.7 setzen und in der make.conf
PYTHON_TARGETS="python2_7 python3_3"
PYTHON_SINGLE_TARGET="python3_3"
Richtig? |
|
| Back to top |
|
|
Christian99
Veteran
Joined: 28 May 2009
Posts: 1668
|
| Posted: Sun Dec 29, 2013 2:39 pm Post subject: |
|
|
| python auf 2.7 und in der make.conf am besten gar nix setzen. so habs ich und keine probleme. |
|
| Back to top |
|
|
ulenrich
Veteran
Joined: 10 Oct 2010
Posts: 1480
|
| Posted: Sun Dec 29, 2013 3:33 pm Post subject: |
|
|
Man kann für jeden ebuild es extra setzen wie für jedes USE flag in der /etc/portage/package.use
<category>/<item> python_single_target_python2_7 -python_single_target_python3_2 -python_single_target_python3_3 |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Mon Dec 30, 2013 6:40 am Post subject: |
|
|
| ulenrich wrote: | | Hey, wenn Du als Publikum nur System-Administratoren hast, deren Englisch eine Berufsvoraussetzung ist, hast Du natürlich Recht. Aber erklär mal einem Asiaten, dass er erst Englisch lernen muss um seine Variablen benennen zu können |
Ich verstehe nicht, worauf Du hinaus willst: Englische Zeichen einzugeben, ist für einen typischen Asiaten genauso normal wie die Bedienung der Maus - Englische Zeichen lernt dort auch jeder, der überhaupt Lesen und Schreiben kann. Aber selbst wenn dem nicht so wäre: Schlüsselworte sind sowieso Englisch und man braucht für utf8-Behandlung keine künstlichen Inkomapibilitäten wie bei print einzubauen.
| Quote: | | Im Ernst, die String Behandlung in Python-2 ist ein solches Durcheinander, voller Workarounds und kompliziert, dass es kaum zu erklären ist. Ich bin froh über einen klaren Schlusstrich. |
Was hat das damit zu tun, dass python-3 um print() zwingend Klammern verlangt, was in der Praxis der Hauptgrund für die Inkompatibilität ist? Es wäre verständlich, wenn in der Anleitung nur noch die Variante becshrieben wird und ggf, mit einem Warnmodus auf die obsolete Schreibweise hingewiesen wird. Aber künstlich mit einem Fehler abzubrechen... andere Sprachen wie C++ oder Perl machen doch vor, wie man neue Features einbauen und dabei trotzdem weitestgehend die Kompatibilität erhalten kann. |
|
| Back to top |
|
|
Jean-Paul
Guru
Joined: 13 Apr 2009
Posts: 307
|
| Posted: Mon Dec 30, 2013 12:20 pm Post subject: |
|
|
| mv wrote: | | Was hat das damit zu tun, dass python-3 um print() zwingend Klammern verlangt,... |
Die Klammern sind deshalb nötig, weil print kein Schlüsselwort mehr ist, sondern eine build-in-Funktion.
| mv wrote: | | ...was in der Praxis der Hauptgrund für die Inkompatibilität ist? |
Die größte Inkompatibilität ist der Datentyp str. In python-2.X gibt es str, was zum Speichern von byte-Folgen verwendet wird und unicode zum Speichern von Text.
In python-3.X gibt es str, was zum Speichern von Text verwendet wird und byte (bzw. bytearray) für byte-Folgen.
Es gibt Konvertierungs-Scripts die ein Großteil der Konvertierung erledigen, aber man muss schon noch selbst gehörig Hand anlegen,
weil python-3 eigentlich eine andere Sprache ist.
Manche Entwickler scheuen diese Arbeit und deshalb haben wir die Situation die wir haben.
_________________
”Everything should be made as simple as possible, but no simpler.” – Albert Einstein |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Mon Dec 30, 2013 11:47 pm Post subject: |
|
|
| Jean-Paul wrote: | | Die Klammern sind deshalb nötig, weil print kein Schlüsselwort mehr ist, sondern eine build-in-Funktion. |
Das ist schon klar, aber es wäre keine Kunst, print zusätzlich als Schlüsselwort zu akzeptieren, um die Kompatibilität beizubehalten.
| Quote: | | Es gibt Konvertierungs-Scripts die ein Großteil der Konvertierung erledigen, aber man muss schon noch selbst gehörig Hand anlegen |
Das kommt ziemlich auf das Projekt an, das zu konvertieren ist. Ich war sehr erstaunt, dass mein Spielzeugprojekt nach den printf-Fixes direkt mit python-3 lief (zugegebenermaßen nur ein bisschen heuristisch getestet), schließe daraus aber auch, dass das für viele weitere Projekte so gilt (so klein war es nun auch wieder nicht, und es enthielt eine Menge Stringbehandlungen). Klar, es war kein spezielles utf8-Projekt, aber das sind viele in python geschriebene Projekte ohnehin nicht: Für die würde eine print-Sonderbehandlung möglicherweise die Konvertierung sparen, und es ist für ein Projekt nur von Vorteil, wenn es mit allen Python-Dialekten funktioniert... |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Deutsches Forum (German)
