# python Version

## flammenflitzer

Hallo,

```
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.

----------

## Jean-Paul

Hi,

 *Quote:*   

> eselect python list
> 
> Available Python interpreters:
> 
>   [1]   python2.7 *
> ...

 

Python-3.2 hab ich gar nicht mehr, wurde imho mit Python-3.3 entfernt.

----------

## mv

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.

----------

## ulenrich

```
# 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?

----------

## mv

 *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.

----------

## ulenrich

 *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  :Sad: 

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 ...

----------

## mv

 *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.

----------

## ulenrich

 *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  :Smile:  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.

----------

## flammenflitzer

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?

----------

## Christian99

python auf 2.7 und in der make.conf am besten gar nix setzen. so habs ich und keine probleme.

----------

## ulenrich

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

----------

## mv

 *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.

----------

## Jean-Paul

 *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.

----------

## mv

 *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...

----------

