Python 3 und Python 2 parallel laufen lassen ?

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.
Antworten
Benutzeravatar
mathman
User
Beiträge: 92
Registriert: Mittwoch 19. November 2008, 08:27
Wohnort: Magdeburg
Kontaktdaten:

Hi,

für eine gemeinschaftliche Bachelorarbeit benötige wir Scipy.
Jetzt haben wir angefangen unsere Module in Python 3 zu schreiben
und sind an einem Punkt angekommen bei dem wir Scipy benötigen.
Dummerweise wurde Scipy noch nicht auf Python 3 portiert :lol:

Jetzt haben wir überlegt wie man Scipy trotzdem nutzen kann.
Ist es möglich Python 2.x und 3 parallel laufen zu lassen ?
Dann könnte man ein Unterprogramm in Python 2.x schreiben was
dann das WGV durchrödelt und uns die Schnittkräfte als Rückgabewert liefert.

Wahrscheinlich gibts dafür eine ganz einfache Lösung, leider fällt mir die
aber nicht ein :K

Unter Linux könnte ich das sicherlich mit der Shebang lösen, doch wie
soll ich das in Windows machen ? Das ganze soll auch auf beiden Systemen laufen :)

Ich hoffe uns kann jemand helfen, denn die andere Lösung wäre den Code komplett
auf 2.x umzuschreiben.

Gruß
Mathman
lunar

@mathman: Was ist daran so schlimm, das Programm in Python 2 zu schreiben? So kompliziert ist das auch nicht.

Im Übrigen kann man derlei Ungemach vermeiden, indem man vor Projektbeginn über die Anforderungen und die Abhängigkeiten nachdenkt.
Benutzeravatar
Hyperion
Moderator
Beiträge: 7478
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

Naja, Ihr könntet das andere Programm (Python2) ja einfach per subprocess-Modul callen - dort gebt ihr halt einfach den Pfad zum Python2-executable an.

Es kommt natürlich auch drauf an, wie oft ihr das benötigt, wie "schnell" das alles laufen soll usw.

Wenn das Berechnungstool wirklich nur für Kleinigkeiten verwendet wird, die Geschwindgikeit nicht entscheidend ist und das ganze wirklich gut vom Hauptteil seprariert werden kann, dann würde ich zum Ansatz mit subprocess raten. Ansonsten würde ich auf Python2 zurückportieren.
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
Benutzeravatar
mathman
User
Beiträge: 92
Registriert: Mittwoch 19. November 2008, 08:27
Wohnort: Magdeburg
Kontaktdaten:

Vielen Dank für die zügigen Antworten

Na ja, in Scipy sollen Rechenoperationen mit großen Matritzen gemacht werden,
also wo wir das mal überschlagen haben waren das so um die 500 Rechenoperationen.

[quote="lunar"Im Übrigen kann man derlei Ungemach vermeiden, indem man vor Projektbeginn über die Anforderungen und die Abhängigkeiten nachdenkt.[/quote]

Ja das stimmt, wir waren eigentlich froh das wir am Anfang Scipy gefunden haben. Da hat noch niemand nachgeschaut obs das auch für Python 3 gibt :shock:

Das ganze Programm ist jedenfalls auf dem Zettel sehr Modular aufgebaut. Wir würden dann her gehen und das Modul
umschreiben, wenn es Scipy unter Py3 gibt. Abgabe des Projektes ist Februar 2011. Da wir da aber noch unseren Master an
der Einrichtung machen wollen, können wir das Modul sicherlich auch später aktualisieren. Hauptsache es funktioniert erst einmal
bei der Abgabe :D
lunar hat geschrieben:@mathman: Was ist daran so schlimm, das Programm in Python 2 zu schreiben? So kompliziert ist das auch nicht.
Sicherlich nicht, aber z.B. unter Ubuntu wird Py2 nur noch bis Ende 2010 unterstützt! Unser Programm bemisst Spannbetondurchlaufträger und soll auch den Rechenweg "per Hand" unserer Meinung nach mit ausgeben. Nutzen daran haben die Studenten die nach uns kommen, da es zur Lehre benutzt werden soll. So nen Programm hätte ich auch gern gehabt um mir unendlich Aufgaben generieren zu lassen mit Lösungsweg. Na ja, jedenfalls soll das Programm länger an der Einrichtung laufen und Py2 wird in geraumer Zeit sicherlich eingestellt werden und dann läufts nicht mehr, ergo programmieren wir das in Py3 für ne länger Lebenszeit :mrgreen:
Hyperion hat geschrieben:Naja, Ihr könntet das andere Programm (Python2) ja einfach per subprocess-Modul callen - dort gebt ihr halt einfach den Pfad zum Python2-executable an.

Es kommt natürlich auch drauf an, wie oft ihr das benötigt, wie "schnell" das alles laufen soll usw.

Wenn das Berechnungstool wirklich nur für Kleinigkeiten verwendet wird, die Geschwindgikeit nicht entscheidend ist und das ganze wirklich gut vom Hauptteil seprariert werden kann, dann würde ich zum Ansatz mit subprocess raten.
Hab das eben mal schnell gegoogelt :)
Versteh ich das richtig, subprocess-Modul ruft einfach nen Programm z.B. in der Shell auf.
Also rufe ich dann z.B.

>>>/pfad/zu/pyhon2 modulname

auf, dann wird das Pythonprogramm in Py2 ausgeführt und gibt mir nen Rückgabewert zurück ?

Inwiefern wird das denn dann langsamer, also wenns insgesamt eine Verzögerung von 1-2 Sekunden hat, solls
mir recht sein.
Benutzeravatar
Hyperion
Moderator
Beiträge: 7478
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

mathman hat geschrieben: Versteh ich das richtig, subprocess-Modul ruft einfach nen Programm z.B. in der Shell auf.
Also rufe ich dann z.B.

>>>/pfad/zu/pyhon2 modulname

auf, dann wird das Pythonprogramm in Py2 ausgeführt und gibt mir nen Rückgabewert zurück ?

Inwiefern wird das denn dann langsamer, also wenns insgesamt eine Verzögerung von 1-2 Sekunden hat, solls
mir recht sein.
Schreib Dir doch einfach mal ein kleines Testscript, in dem Du ein "Hallo Welt"-Script in Python2 geschrieben per subprocess aufrufst.
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
BlackJack

@mathman: Also ich bin da sehr skeptisch was Deine Zeitvorstellungen bei Python 3 angeht. Weiss auch nicht was Du mit Ubuntu's Unterstützung meinst. Die werden sicher noch so lange Python 2 ausliefern und Zusatzpakete anbieten wie noch nicht alle wichtigen Programme und Rahmenwerke portiert sind und das lässt sich weder bis 2011 erzwingen noch sehe ich das wirklich bis dahin kommen.

Vom Bibliotheksangebot her macht es IMHO immer noch Sinn auf Python 2.x zu setzen. Natürlich sollte man die Portierung im Auge behalten und mal das 2to3.py-Werkzeug drüberlaufen lassen und den Code so gestalten, dass danach nur wenig per Hand geändert werden muss, aber ausschliesslich auf Python 3 zu setzen, weil's so schön neu ist…
fhoech
User
Beiträge: 143
Registriert: Montag 9. April 2007, 18:26

mathman hat geschrieben:(...) unter Ubuntu wird Py2 nur noch bis Ende 2010 unterstützt!
Ich kann im Ubuntu-Wikieintrag zu Python nur den folgenden Satz finden: „Python 2.x wird mindestens bis Ende 2010 voll unterstützt und gepflegt.“

Ehrlich gesagt, würde es mich wundern wenn die Unterstützung für 2.x in den nächsten – sagen wir mal drei – Jahren tatsächlich auslaufen würde; darüber hinaus sind auch (afaik) noch gar nicht alle Systemskripte nach 3.x portiert :)
Benutzeravatar
noisefloor
User
Beiträge: 3856
Registriert: Mittwoch 17. Oktober 2007, 21:40
Wohnort: WW
Kontaktdaten:

Hallo,
fhoech hat geschrieben:Ich kann im Ubuntu-Wikieintrag zu Python nur den folgenden Satz finden: „Python 2.x wird mindestens bis Ende 2010 voll unterstützt und gepflegt.“
Mist, erwischt. :lol: Der Satz ist veraltet und stammt noch aus einer Zeit, als geplant war, dass Python 2.6 die letzte Python Version 2.x werden sollte. Ubuntu 10.10 Maverick hat Python 2.x an Bord, der Support läuft bis 12.04. Du kannst aber davon ausgehen, dass auch Ubuntu 11.04 Natty noch Python 2.x an Bord hat.

Genug dazu, ich muss mal schnell einen Wiki-Artikel korrigieren... ;-)

Gruß, noisefloor
Dadapf
User
Beiträge: 28
Registriert: Mittwoch 16. Dezember 2009, 09:16

Guten Morgen,

was spricht dagegen, Python 2 und 3 parallel laufen zu lassen?
Meine bisher nötigen Programme habe ich alle auf Python 3 portieren können; habe das Problem so bis jetzt noch nicht gehabt. Einzig der neulich installierte Python-http-Server läuft noch unter Python 2 und verträgt sich bis jetzt mit Python 3-Skripten.

Dadapf
BlackJack

@Dadapf: Grundsätzlich spricht nichts dagegen. Nur beides in *einem* Programm!? Das bedeutet ja, das es bei Endanwendern auch beide Python-Versionen voraussetzt. Und man muss im Programm im Auge behalten welche Module auf der einen und welche auf der anderen Python-Version laufen. Das ist ja nicht auf immer auf den ersten Blick ersichtlich am Quelltext, wenn man es nicht dokumentiert.

Speziell bei dem OP stellt sich die Frage nach den Reibungsverlusten beim Austausch zwischen den beiden laufenden Python-Prozessen.
Dadapf
User
Beiträge: 28
Registriert: Mittwoch 16. Dezember 2009, 09:16

Hm, ersichtlich sollte es eigentlich sofort im Quelltext sein, da ja auf die unterschiedlichen Binärdateien verwiesen wird - zumindest bei mir: /usr/bin/python und /usr/bin/python3.
Inwieweit es Probleme im Konstrukt des OPs gibt, ist naturlich eine weitere Frage. Meine ist zu Hälfte allgemein gewesen. Danke für die Antwort.

Dadapf
BlackJack

@Dadapf: Ich bin bei "parallel" davon ausgegangen, dass man wirklich *ein* Programm hat, wie der OP. Und es gibt ja nicht in jedem Modul diese erste Zeile sondern in der Regel nur in denen, die man auch direkt als Programm ausführen kann.
Dadapf
User
Beiträge: 28
Registriert: Mittwoch 16. Dezember 2009, 09:16

Bei mir stehen die beiden Zeilen

Code: Alles auswählen

#! /usr/bin/python3
# -*- coding: utf-8 -*-
am Anfang jedes Moduls, auch wenn es eigentlich keinen Sinn hat, dieses alleine laufen zu lassen. Aus praktischen Gründen - der Test des Moduls selber - habe ich mir jedoch angewöhnt, ein Modul so zu programmieren, dass es auch alleine lauffähig ist.

Dadapf
Pa5tA
User
Beiträge: 21
Registriert: Sonntag 1. August 2010, 16:37

Also ich denke Python 2 wird noch lange unterstützt werde... Ich meine ich kenne nur eine Distribution die bis jetzt offiziell auf Python3 umgestellt hat (also /usr/bin/python ist python3), das ist Archlinux. Und auch dort kann man noch problemlos über /usr/bin/python2 Python2 Programme ausführen. Also einfach an den Anfang anstatt python python2 schreiben und das Programm wir die naechsten Jahre bestimmt noch laufen.
Benutzeravatar
mathman
User
Beiträge: 92
Registriert: Mittwoch 19. November 2008, 08:27
Wohnort: Magdeburg
Kontaktdaten:

vielen dank für eure Antworten :)

also ich habe leider keinerlei Dokumentationen geschweige denn Literatur für Python hier, liegt alles bei mir zu hause :(

so, da hab ich dann mal mit dem internet und try and errror was probiert, was natürlich nicht funktioniert.

Code: Alles auswählen

import subprocess
process = subprocess.Popen(['python' 'py2prog.py'], stdout=subprocess.PIPE)
print(process.stdout.read())
mag daran liegen das ich subprocess nicht mal ansatzweise verstanden habe :oops:

Ich habe im Internet eben ein wenig recherchiert und Numpy scheint es sogar schon für 3 zu geben :D
da ist wie gesagt nur Scipy noch offen ...

Ich habe die Info das Python2 ausläuft wirklich aus dem Wiki von ubuntuusers. Gut dann war das wohl eine Fehlannahme ...
Da ich ja Python erst mit dem Projekt lerne dachte ich auch das es besser sei gleich auf das neue zu setzen, da muss ich dann mir nicht mehr 2 und danach 3 beibringen :K
BlackJack hat geschrieben:@Dadapf: Grundsätzlich spricht nichts dagegen. Nur beides in *einem* Programm!? Das bedeutet ja, das es bei Endanwendern auch beide Python-Versionen voraussetzt. Und man muss im Programm im Auge behalten welche Module auf der einen und welche auf der anderen Python-Version laufen. Das ist ja nicht auf immer auf den ersten Blick ersichtlich am Quelltext, wenn man es nicht dokumentiert.

Speziell bei dem OP stellt sich die Frage nach den Reibungsverlusten beim Austausch zwischen den beiden laufenden Python-Prozessen.
Was ist ein OP ?
Also wenn Numpy unter Py3 laufen sollte (steht bei Wikipedia, auf der Homepage von Numpy hab ich es noch nciht gefunden) dann gibt es nur ein einziges Modul was auf Scipy und damit Python2 zugreifen muss.
Sicherlich ist es blöd das der Anwender 2 Versionen installieren muss. Das Programm soll aber unser erachten nach auf einem Server laufen und soll mit einem Http Interface bedient werden. Demnach ergibt sich das Problem erst wenn man es verteilt. Vielleicht haben wir auch Glück und bis Februar gibt es Scipy auch für Py3 :)

Gruß
BlackJack

@mathman: "Funktioniert nicht" ist eine unzureichende Fehlerbeschreibung. Passiert gar nichts? Bekommst Du eine Fehlermeldung? Explodiert der Rechner? Rennt die Maus wild piepsend davon?

OP = "original poster", also derjenige der den ersten Beitrag verfasst hat, also in diesem Falle Du. :-)
Benutzeravatar
snafu
User
Beiträge: 6738
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

noisefloor hat geschrieben:Ubuntu 10.10 Maverick hat Python 2.x an Bord, der Support läuft bis 12.04. Du kannst aber davon ausgehen, dass auch Ubuntu 11.04 Natty noch Python 2.x an Bord hat.
Ist das jetzt dein persönlicher Eindruck oder die offizielle Planung? Ich mein, das aktuelle Ubuntu hat noch nicht mal auf Python 2.7 umgestellt. Muss ich mir jetzt so vorstellen, dass man für Natty auf 2.7 umstellen wird und danach auf 3.2 springt oder wie wird es ablaufen?

EDIT: Huch, zwischen 11.04 und 12.04 ist ja ein *Jahr*... :oops:
mathman hat geschrieben:so, da hab ich dann mal mit dem internet und try and errror was probiert, was natürlich nicht funktioniert.

Code: Alles auswählen

import subprocess
process = subprocess.Popen(['python' 'py2prog.py'], stdout=subprocess.PIPE)
print(process.stdout.read())
mag daran liegen das ich subprocess nicht mal ansatzweise verstanden habe :oops:
Da solche Probleme mit dem `subprocess`-Modul sehr oft auftauchen und dieselben Leute dann leider häufig dazu neigen, `shell=True` zu verwenden, habe ich executie als eine Art Wrapper geschrieben (der natürlich auch als Beispiel für die eigene Implementierung genutzt werden kann). Im Prinzip sind es nur ein paar Zeilen Code, aber vielleicht hilft es dir. :)
Benutzeravatar
mathman
User
Beiträge: 92
Registriert: Mittwoch 19. November 2008, 08:27
Wohnort: Magdeburg
Kontaktdaten:

snafu hat geschrieben: Da solche Probleme mit dem `subprocess`-Modul sehr oft auftauchen und dieselben Leute dann leider häufig dazu neigen, `shell=True` zu verwenden, habe ich executie als eine Art Wrapper geschrieben (der natürlich auch als Beispiel für die eigene Implementierung genutzt werden kann). Im Prinzip sind es nur ein paar Zeilen Code, aber vielleicht hilft es dir. :)
Hi,
habs leider nicht damit hin bekommen. Werde mich in geraumer Zeit mal mit dem subprocess beschäftigen. Gibts dazu auch Literatur in deutsch oder nur die original Doku?

Hatten gestern eine lange Diskussion und wir werden wahrscheinlich das Programm erst einmal in Python 2 schreiben da dort alle Module laufen. Wenn man das in Py3 portiert kann man ja das Py2toPy3 Tool nutzen, mal sehen ob das funktioniert :mrgreen:
Antworten